If asked, we would have advised to use the backup and restore functions in the LE settings add-on.
Posts by chewitt
-
-
The file plays software decoded on an RPi5, albeit with an abysmal frame-rate (but frames are rendered). Have you done previous tests on the same 1080p display device? - forcing Kodi to downscale 4K prores to 1080p probably doesn't help the cause.
-
Probably impossible for the thread starter, and needs further explanations.
Most device-tree files are visibly littered with 'status' describing whether something should be 'enabled' or 'disabled' so as long as you have half a clue about includes/dtsi it's 'not rocket science' to disable something in a specific board dts that was enabled in the inherited board family or SoC dtsi.
-
The WiFi module is part of the RK3566 SoC, so not removable
That is incorrect. The WiFi module is a separate chip (Cypress CYW43455 according to schematics on the Pine64 website) connected to SDIO (WiFi) and serial UART (BT) lines of the SoC but not functionally part of the SoC itself. The module it always is a separate chip package soldered to the main PCB.
It would be easier to disable the SDIO/BT module through device-tree changes (disable the sdio node, disable the BT node) than to physically modify the board by unsoldering chips, although that could also be done if you have the tools/skills.
-
Mainline u-boot overwrites the 'memory' node in device-tree with what it detected, so 1MB is corrected to 2MB, whereas Amlogic u-boot uses the value described in device-tree, hence all the 1g/2/3g dtb variants you find in vendor kernel sources.
-
S905X5M SOC not supported yet? I think there is no dtb for it yet.
Amlogic are slowly upstreaming support for newer chips, but emphasis is on 'slowly' so ask me again in 2-3 years.
-
And it was already LibreELEC with iwd?
Correct.
-
1. I'll have to ask the upstream kernel maintainers if suspend/resume are supported and expected to work. I won't guarantee it.
2. In theory the kernel should handle the display device going away and coming back. Kodi only checks things at startup though so might not handle things properly even if things lower in the stack do. In either case the workaround will be (or should be) to run the 'getedid' script so the kernel (and thus Kodi) always sees the display device (via it's EDID data) as connected.
3. If you are using official nightlies please try the latest image in my testing share and see if that fixes the issue? - I've added some kernel options to make iptables work but can't remember if that change has made it into official nightlies. I'm also unsure if I added all the options for Docker though.
-
Seems like your USB drive is broken
That's no the problem, because of how LE is packaged. To explain:
In a conventional distro there are many thousands of files stored on disk with each file occupying at least one sector and some occupying many sectors. Bad sectors thus impact only a small number of files and if those are non-critical files you might throw some odd errors but the system keeps running until you do finally lose something important.
LE is packaged as two compressed read-only files (KERNEL and SYSTEM) which are expanded into a virtual root filesystem on boot, with persistent storage (containing largely non-critical data) in /storage. If you have a bad sector impacting either KERNEL or SYSTEM their decompression fails fatally and the OS does not boot.
Thus if the system boots, some odd USB errors from the boot drive were not fatal and the OS (in its entirety) is running.
The log shows USB device 1-3 being mounted as /dev/sda without any issues. This is the boot device.
The log shows USB device 1-4 throwing usb 1-4: string descriptor 0 read error: -22 but this is not the boot device.
The log also shows Xorg failing to start an i915 (Intel GPU) card due to lack of DRI2 or DRI3.
I would do the following:
- Run "systemctl stop kodi" to stop the Xorg boot loop.
- Move /storage/.kodi to /storage/.kodi-old to sidestep possible add-on issues
- Use "connmanctl" to connect to WiFi and the Internet if needed (looks to have a stored config so prob. not needed)
- Download (wget) the latest nightly 'Generic' (not Generic-Legacy) image to /storage/.update
- Reboot to update
Switching to the Generic (GBM) image should sidestep the issue with Xorg and leave you with a working system?
-
Clean install using defaults and the internal Broadcom WiFi card. No Ethernet active so WiFi only on boot.
The single time I’ve seen this error was on a WeTek Play2 box; also using a BCM chip but no power pulling was involved, and it hasn’t been seen again since. The box is only used on WiFi due to lack of free Ethernet cables.
-
Code
U-Boot SPL 2017.09-ge4e124926e-230922 #lxh (Sep 25 2023 - 10:58:38), fwver: v1.13You have an ancient Rockchip vendor u-boot installed (pre-installed by Radxa) in the SPI flash. Clear/erase the SPI flash and the board will boot from the SD card properly.
-
You can enable "disable password authentication" in the SSH service settings (in LE settings). Once this has been set there will still be a login prompt, so you can attempt password auth, but no password is accepted.
-
Code
<KEY_B>runScript(script.audio.profiles,0)<KEY_B> <= two opening tags <KEY_B>runScript(script.audio.profiles,0)</KEY_B> <= one opening, one closing tagIn the xml snippet you posted, KEY_B has no closing tag ^
-
But kodi doesn't move the files on the server: I'm confused.
Kodi is dependent on the structure you create, it will not restructure/move/tidy things up for you. So you need a consistent structure and then (via advancedsettings.xml, which you create if it doesn't exist) you map that structure by telling it where the extras folder will be (consistently, if you want consistent results).
-
If you found some pre-compiled module somewhere on the internet then you are stuck with trying to use a specific kernel version as the 'version magic' must match for the kernel to load the module.
Unless the driver code is shockingly bad: If you're going to compile the out-of-tree module (as you have stated) it can be built against whatever kernel version is latest/used in our buildsystem and you don't need to care about the version.
NB: User attempts to shortcut compiling in our buildsystem "because compiling an image takes ages" with some module compiled outside our buildsystem "because it'll be quicker" usually result in the user expending considerably more time/effort/frustration on the shortcut than just compiling the image in our buildsystem would have taken.
-
leo kalmaev You need to share the serial UART output from the board so we can see what happens during boot. There is no need to mess around with SPL loader tools. You image an SD card with the LE image, and as long as there is no other u-boot stored in SPI or eMMC to take priority, LE will boot its own u-boot from the SD card. If you want to run LE from eMMC, either mount the module via a USB/eMMC adaptor and write the image to it like an SD card, or boot from SD first, download the image to /storage, then use the "emmctool" script to write it to the eMMC device. Do not use vendor "write image direct to emmc" loader tools (as our .img is not created for them and won't work).
-
If you would try, you'd be able to replicate the issue! Important: only after ungraceful shutdown! That's why it seems random to many users. It is not!
I have tried, with an RPi4, and lots of ungraceful shutdowns. I managed to corrupt something in Kodi one time, but I don't have any issues connecting to WiFi with the board in the same room as the router (1.5m distance) or in the next room (2m distance, but walls 50cm thick and full of steel rebar). I simply do not see the issue.
-
Can someone please suggest what I can do to resolve the above and get a HDMI signal?
The 'getedid' script can be used to workaround scenarios where the TV is powered on after the RPi board. It does not perform any other magic to make connections work. There is normally no need to use it, and it can complicate troubleshooting.
Start over with a fresh/clean SD card to remove getedid changes and because most of what's added to config.txt and cmdline.txt is no longer supported or incorrect.
- Add video=HDMI-A-1:1920x1080M@60D to kernel boot params in cmdline.txt
- Connect the RPi4 micro-HD cable to the port nearest the PSU connector
- Connect the HDMI cable to the newer LG TV
The video= param will force the kernel DRM connector state to 1080p@60 to avoid issues with 4K modes the TV (or cheap cables) don't like. Does that solve the problem?
NB: CEC control will only work on the HDMI-A-0 connector nearest the PSU, it is not supported on HDMI-A-1.
