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.
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?
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.
The fp-dev component sounds like an MCU so it's probably attached via i2c, but is also probably a custom part so you would need infos or sources from the manufacturer (or proper reverse-engineering skills) to figure it out.
Do you have any high-resolution PCB photos? - is there an RTC chip and power cell attached? - I would expect yes (to support timed wake and record) but there is no mention of this in the vendor kernel device-tree or sources.
Updated LibreELEC-AMLGX.arm-9.95.1-box.img.gz image has RC keymaps added and I removed button things as those are likely wrong too. I moved the LED to GPIOAO_3, but this is just a random guess.
Bump v4.9.113-641429-g1883b89 · emanuel4you/linux-meson64@7f99a65 · GitHub
^ this is probably why the LED doesn't work - and you can see 11/4 are in use for other things. In the absence of schematics the best thing to do is boot an original dreambox kernel and see what is set there. It might be a PWM config rather than GPIO, or a different GPIO_AO?
_emanuel_ Updated LibreELEC-AMLGX.arm-9.95.1-box.img.gz image has two device-tree files for dreambox one/two that I created earlier. Please test whether the LED/button bits work. There are no RC keymaps in the image - I can see the BSP kernel keymaps, but there are 4x maps. If you can explain which keymap is used in which box I will add them.
See last four commits here: Commits · chewitt/linux · GitHub
I moved the posts. Please share a URL to a GitHub repo with the dtb or patches (or share the patches) and I will see what changes might be needed for the LEDs and buttons. It should be simple to add.
It is technically possible but a bad idea since LE is not designed for exposing internet-facing services - both from a security and sharing protocols perspective. Don't be a shodan.io statistic!
