Posts by JORGETECH

Quote from jernej

Nope, pine64-plus is correct, one with underscore is old and it was renamed.

Ooops, sorry you're right. I was referencing older scripts from the 9.2.x series.

Quote from johnpaul

Can anyone tell me what compile command is being used to create the nightlies for the Pine 64+?

I'd like to compile it myself, but I can't find any documentation about compiling LibreElec.

Would it just be the following?

PROJECT=Allwinner ARCH=arm DEVICE=A64 UBOOT_SYSTEM=pine64-plus make image

I'm getting errors with this command.

You can find compile instructions here, check out the build commands for LibreELEC 10.x on that page for information on how to compile for your platform (you can also add "UBOOT_SYSTEM=pine64_plus" before "make image" in your case). I think your mistake was to use "pine64-plus" instead of "pine64_plus".

Quote from jernej

I'm considering changing policy regarding boards with less than 1 GiB RAM - they would be accepted in main repo and thus nightly images would be available. However, support for them would be provided by community - I will ignore issues reported on those boards.

What do you think?

If you do that skip the Orange Pi Zero (H2+), since the composite out support is missing in mainline (unless someone with the knowledge wants to work on that of course).

Quote from pacobeat

Youre so kind!!! Thank you so much! Ill try to install and update and report if settings preserved and BT works

No problem! If you want to try to upgrade to the latest nightly after (cleanly) installing my image you can drop the latest nightly image for your board from test.libreelec.tv inside the "Update" folder in your board's Samba share as described here.

Quote from pacobeat

So there´s some older version with working Python 3.7? And with that working Wifi and BT?

Of course, you can compile your own image based on the commits before the change (I made instructions that can be found on page 71). But if you don't want to go through that trouble I compiled an image based on upstream before Python was upgraded to 3.8. After installing that version and configuring your network you can also install the latest nightly using the upgrade images, network settings will be preseved but you won't be able to change it (I think), I don't know if the same applies to Bluetooth since I don't use it.

My image: https://mega.nz/file/3sVmSTIQ#…LVpzHc5LTBftLao

Digital signature of the image (sha256): hastebin

Quote from jernej

Wifi password issue is known and it's due to update to Python 3.8. In order to fix it, part of LE settings addon has to be rewritten and it's actually strange that it worked so long (dbus library used by addon was deprecated long time ago). However, this will take some time. Two possible workarounds - build your own image with downgraded python or set up wifi over ssh (I believe it can be done with connmanctl, but I'm not 100% sure)

Is this already being worked on? Is there any issue or pull request where I can follow the progress?

Quote from jernej

Wifi password issue is known and it's due to update to Python 3.8. In order to fix it, part of LE settings addon has to be rewritten and it's actually strange that it worked so long (dbus library used by addon was deprecated long time ago). However, this will take some time. Two possible workarounds - build your own image with downgraded python or set up wifi over ssh (I believe it can be done with connmanctl, but I'm not 100% sure)

For those that want to compile a version that "fixes" this issue this is what you have to do:

1. Follow the official compiling instructions and stop before the "make" command for your board.
2. Run the next command to revert the specific commit that upgrades Python to 3.8 (be sure you are inside the "LibreELEC.tv" directory): Unfortunately, reverting the commit is not enough since there is another bug where the addons disappear after a reboot, which means that the best workaround is to rebase using the commit preceding the change:
   git checkout 27d6021a3a897e627426a6d5589320d9927c6f2f
3. A text editor will automatically open in the terminal after executing the last command, uncomment the lines with the changes, save the changes and quit.
4. Up to this point the commit should be reverted, in order to check it open the file "package.mk" in the "http://LibreELEC.tv/packages/lang/Python3/", it should have the next line:
   PKG_VERSION="3.7.8"
5. Now you can continue with the compiling process by executing the respective "make" command for your board.

I would upload a working image to a file sharing service (for the newbies) but I'm not sure if that's against the forum rules or not. Can I do that? If I'm permitted to do that I will edit the post accordingly. Here is a working image I just built based on the commit I mentioned in the instructions (sha256 hash here) : https://mega.nz/file/3sVmSTIQ#…LVpzHc5LTBftLao

Quote from StaticallyLinked

I edited my last post, but it was after you had posted this (that's the risk involved with having to approve all replies).

I tried SPI with a different image (one that works), and it has the same "couldn't map SRAM to device" error, but after that it loads the kernel...

I think the problem is not related to those messages and instead happens when uboot tries to load the kernel... but alas, I think there is no way see what happens.

The problem maybe related to UBoot, the weird thing is that a freshly compile nightly of Armbian works but a LibreELEC one doesn't, I don't know of they are using different UBoot sources. I would compile myself an older version of LibreELEC but I don't know which commit broke things.

Quote from StaticallyLinked

Thank you!

I was able to do it and I can confirm the issue is the same and hasn't been fixed as of version 10.10.

hastebin

EDIT: I played around a bit and it seems to happen with a fresh install too (first boot decompresses the image, second boot hangs up). On a side note, something similar has been happening with Armbian for a while now, not sure if it's the same cause or not.

At first glance it doesn't seem to be related to Armbian's problem, the logs attached there show that the kernel at least boots, in our case the kernel fails to boot because of that SRAM mapping error.

Quote from StaticallyLinked

I also had the thought. I have a usb2ttl dongle and I'll try later. Is this the correct way to do it?

Yes, that's the correct way to do it. You should instantly get a log if you did it right.

Quote from StaticallyLinked

Thank you for your reply!

Now I have a different issue. After updating to versions 05.10 and 06.10 for opiLite2 after a restart the system doesn't go past the boot logo (where it says "LibreELEC(community) nightly-xxxx-xxxx"). At first I thought it was because I simply unplugged the power that the fs got corrupted, but the last time I did everything properly and it still got bricked.

Steps to reproduce:

1. Install version 05.09

2. Update to latest nightly

3. Setup the usual things + weather and samba client

4. If it doesn't brick on the next restart it bricks on the one after that.

5. After it gets bricked I can't SSH, probably because the network is not up at this stage

I didn't have this issue before. I will try it without updating from version 05.09.

Display More

Maybe you are running into the same issue I described in my latest post, do you have the ability to output the log using UART serial?

Quote from JORGETECH

I didn't have any problems by using that method

I may have jinxed it by saying that! I upgraded to the latest nightly and now the system gets stuck at "waiting on Network to come online". Is there any way to enable a serial console or log on H6 devices in order to see what is happening? Ok, it was enabled by default.

I managed to get a log, UBoot seems to work fine but the kernel throws a nasty error:

[    0.173612] sun50i-de2-bus 1000000.bus: Error couldn't map SRAM to device

I don't understand why that's an issue since I am running the correct image for my device (Orange Pi Lite 2 with Allwinner H6), kernel regression?

Quote from StaticallyLinked

@JORGETECH, how did you perform the update - fresh install or on top of your previous working version? I tried the OrangePi Lite2 image from 24.09 and still no luck.

Hi, sorry for the delay on my answer but I've been very busy. The method you linked is very similar to the one I use to update through nightlies, as of now I didn't have any problems by using that method. I don't even use SSH for performing the update, I just download the latest nightly on another device and access the LibreELEC device though Samba and copy the compressed image to the Update folder, after a reboot the update process begins and deletes the compressed image once it finishes.

On an unrelated note, I want to know if anyone else is having stability issues with the YouTube add-on, it's the one I use most of the time and sometimes it crashes Kodi when I play a video (it's been doing it on all nightlies), and once it crashes it sometimes gets into a loop of Kodi trying to start but crashing before reaching the main screen (the only way out is to power off the device). I'm using MPEG-DASH to select the quality if that's related.

Quote from jernej

ilyaigpetrov  Gass  StaticallyLinked Kodi and LE settings addon were just updated, please re-try next nightly image. LE settings addon has some fixes in it, which may help, but can't say for sure. I'll check commit history to see what could cause that issue.

EDIT: If kernel is really ok, I would bet on Python update (from 3.7 to 3.8). LE settings addon has some fixes for that.

I updated to the latest nightly image (2020-09-23, 4722b9e for Orange Pi Lite 2) and I haven't encountered any network issues so far (using Wi-Fi). I didn't upgrade to the problematic nightlies so I wasn't having the issue in the first place.

Is anyone having problems with the backup and restore feature? Backups are working fine but every time I time to restore on a new image it pops up the dialog the the progress bar and immediately closes without doing anything.

Quote from jernej

Well, I wouldn't say that. If patches would be present in mainline already, there wouldn't be need to have them. I also don't see such patch in Armbian, so I suspect it's original work from PR author. Anyway, soon PR will need a rebase becasue patches pulled from linux-next will break it.

When you say "linux-next", are you talking about Torvald's mainline kernel?

Anyways, for the moment I'll build from the PR author's github until the rebase happens. I really want to test this board and give feedback since Armbian is already working great on it.

Quote from jernej

JORGETECH There is PR open allwinner: add initial support for H6 orangepi-lite2 board by prabuselva · Pull Request #3961 · LibreELEC/LibreELEC.tv · GitHub which should work. Maybe I asked too much from the author...

So those come from armbian and mainline kernel, as I expected. As far as I understand I could fetch the commits from that pull request, do I need to also make an specific "target" for the Orange Pi Lite 2? Where are the target files for the supported devices located in the git repo?

jernej Do you think an Opi Lite 2 image is possible now that the Opi 3 and One Plus are supported? The only differences I can think of are the different WiFi chip (AP6255 vs. AP6256 on the Opi 3) and only one USB 3 port (without hub chip, I think).

I'm sure those differences can be solved using DT bindings, but I have no idea on how to use those on the LibreELEC compilation stack (I would also be thankful if someone could lead me to a wiki or give me advice on that).