Posts by chewitt

The FIPs contain RAM timing data (acs.bin) so if this is wrong the box doesn't boot, which is not impossible to recover from but needs you to short emmc pins to prevent [wrong] vendor u-boot from being found/used. If I want to experiment I will take a backup of emmc then zero emmc. The box will then boot the experimental signed u-boot from USB/SD card, and worst case if nothing works I can put vendor u-boot on an SD/USB to recover the system. If you can get u-boot sources it's simple to extract the FIPs. Alternatively, if they will not share the sources, please loop me into an email conversation with the developers and I can explain which files I want.

Do you see the same behaviour in the LE10 beta?

Please fork u-boot on GitHub and push changes. It is sometimes hard to follow your descriptions (lots of enthusiasm, but light on technical detail) so commits in a branch are always good to review

I moved your post - please do not hijack random threads.

It probably needs changes in the greeksubs add-on to handle redirection to sites with self-signed certificates, i.e. accept them.

Settings > Services > Control .. Did you enable the web interface?

I've not heard a high-pitched hiss before, but full-range staccato a.k.a "Machine Gun" noise is a known driver problem. I've not seen lockups from this though, so it would be good to capture "journalctl | paste" when that happens to see if there are error messages?

p.s. I'm aware of the older device-tree (original source for CE is an LE repo).

Also update to LE10b1 .. there are many changes/fixes. Maybe problem already fixed?

LE settings Add-on > Services. In Estuary skin the add-on is linked in Kodi settings. In other Skins you may only find it under Program Add-ons.

Do not add ".apps.googleusercontent.comSecret" to the info being presented. Below is an example of how a working config looks (with some random characters in the keys changed).

In /storage/.kodi/userdata/addon_data/plugin.video.youtube/settings.xml:

    <setting id="youtube.allow.dev.keys">true</setting>
    <setting id="youtube.api.config.page" default="true">false</setting>
    <setting id="youtube.api.id">955724949404-88ed74c3e6e73e8ch35t9qr15t0ab7rb</setting>
    <setting id="youtube.api.key">AIzaSyDi4CaM69OCjHDfr2GZ1WYZM3w7oMEzGsY</setting>
    <setting id="youtube.api.secret">C760ubRG-KAYR3pglQyc5m1n</setting>

In /storage/.kodi/userdata/addon_data/plugin.video.youtube/

{
    "keys": {
        "developer": {},
        "personal": {
            "api_key": "AIzaSyDi4CaM69OCjHDfr2GZ1WYZM3w7oMEzGsY",
            "client_id": "955724949404-88ed74c3e6e73e8ch35t9qr15t0ab7rb",
            "client_secret": "C760ubRG-KAYR3pglQyc5m1n"
        }
    }
}

First line of Log:

2019-04-11 16:28:40.923 T:3012019536 NOTICE: Starting Kodi (18.9 (18.9.0) Git:leia_pi4_18.9-Leia). Platform: Linux ARM 32-bit

Last line of Log:

2019-04-11 16:42:38.308 T:3012019536 NOTICE: XBApplicationEx: application stopped!

RPi has no RTC chip. If network does not provide NTP correctly dateTime starts from GCC release date. If this happens system dateTime is before start date for TLS certificate in Kodi repository and (on your system) certifcate not valid so Kodi cannot connect to repo.

Something is wrong with NTP process in your environment. We cannot see problem from Kodi log, need system log.

Share URL from "journalctl | paste" or "journalctl -b 0 --no-pager > /storage/log.txt" and copy to pastebin site.

Пишите по-английски пожалуйста.

You could route audio in the OS layer but Kodi has no concept of "line in" so it won't be GUI controllable.

Can you see if audio works correctly if you set Kodi to "fixed" 44.1Khz output? - I need to do this on WP2 and have a theory there's a difference between S905 and newer S905X/S912 devices that's not handled in the audio driver.

If I have time over the weekend I'll create a proper device-tree for the U1, it also has an RTC chip onborad which should be simple to add. The photo of the board I found MINIX_NEO_U1_Board_Large.jpg shows 3x LEDs but the legacy kernel dtb device-trees-amlogic/gxbb_p200_2G_minix_neo_u1.dts at master · LibreELEC/device-trees-amlogic · GitHub mentions "minix_mcu" so these might not be controllable without a custom MCU driver (which doesn't exist and isn't likely to be written).

The Beelink G12B devices I have all experience some kind of kernel lockup when using vendor u-boot, with or without chainload of any recent newer u-boot as second stage; although in that case LE boots and generally runs fine until you attempt any large file transfer and then it locks up. Nobody has been able to put their finger on the issue. Beelink shared their u-boot sources so I could see the git history of their changes, but nothing stood out as unusual. Using their sources I extracted the signing FIPs and built mainline u-boot which works without any issues, so this suggests there's an issue in Amlogic u-boot code. G12A/B devices also have confirmed silicon bugs with mmc (there are workarounds in upstream kernel code). So it's hard to comment, but I generally don't trust vendor u-boot + chainload on G12A/B devices.

If you have Amlogic burning tool and an Android ROM (to restore the box with) you could zero/erase emmc to remove vendor u-boot and see if any of the mainline u-boot images I have in my test folder will boot the box from SD card. Otherwise I don't really have ideas.

Quote from milo

Is the boblight plugin ported to libreelec10.1?

It exists, but whether it works is an entirely different question.

[ 2.298762] Run /init as init process

^ the boot log stops here because of the console ordering you've defined in boot params (the order matters):

systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0 <= correct ordering

console=ttyAML0,115200n8 console=tty0 no_console_suspend systemd.debug_shell=ttyAML0 <= yours

I also use boot=LABEL=LIBREELEC, disk=LABEL=STORAGE instead of UUIDs, so see if that makes a difference?

Quote from seias

Can some1 help me distinguish which .DTB is for minix neo ui ?

NEO U1 is a GXBB (S905) device and looking at MINIX_NEO_U1_Board_Large.jpg it has Broadcom WiFi/BT and the standard RTL GB Ethernet, so the WeTek Play2 dtb is a close match and a good starting point for creating a proper device-tree. Please boot from LibreELEC-AMLGX.arm-9.95.1-box.img.gz with WP2 dtb set in uEnv.ini and assuming Ethernet worked, run "dmesg | paste" and share the URL generated. You'll need a USB keyboard attached as the predefined IR keymap will be wrong .. but we can fix that easily.

In theory we could switch to the same 64/32 arrangement we run on other ARM SoCs, but since the current 'arm' kernel still allows access to 4/8GB RAM on larger RPi4 models (not that LE needs it) and the Pi Foundation development focus remains on arm (which is highly optimised) there's no rush/need - although I expect it will happen at some point.