Posts by chewitt

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.

Quote from Da Flex

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.

U-Boot SPL 2017.09-ge4e124926e-230922 #lxh (Sep 25 2023 - 10:58:38), fwver: v1.13

You 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.

<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 tag

In the xml snippet you posted, KEY_B has no closing tag ^

Quote from mune

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).

Quote from treysis

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.

Quote from harryw66

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.

Quote from treysis

It's a bug in iwd and/or the underlying broadcom driver. It doesn't have to do with signal strength or WPA mode as others suggested.

Unless you can prove it, this is opinion not fact.

Quote from emveepee

pcie_aspm=off

There are numerous reports of PCIe issues on kernel mailing lists for Rockchip and Amlogic hardware due to ASPM changes merged for Linux 6.18 that are now surfacing in rc1/rc2 tests. On those platforms earlier kernels don't see the problems (and LE12.2 is using Linux 6.16.y) but I'm wondering if x86_64 is somehow different ..

The Kodi GUI won't show until the 'wait for network' timeout is reached and date/time will be wrong as NTP didn't correct it, but Kodi should still run without a network.

Lots of RK boards ship with some kind of older/vendor u-boot installed in SPI flash and these might not support our extlinux.conf boot files. The solution to that is erasing SPI flash so the mainline u-boot on the SD card is found/used instead.

LE9.0 used the Rockchip Linux 4.4 vendor kernel and we've since switched to the upstream kernel.

I've added an item to my list to investigate further but the latest vendor kernel (Linux 6.6 + mountains of patches) lags so far behind the upstream kernel (Linux 6.18) the differences are huge and playing "spot the difference" isn't fruitful, and that's before you factor in the general impenetrable-ness of kernel audio things.

In short, no promises.

I'm new to the world of Rockchip and unaware of past changes and workings, but PT is not working with any of the newer boards I have and unhiding the option via appliance.xml doesn't achieve anything.

For my knowledge, was the previous version an official LE release or a homebrew community image? .. and what version?

I have no issues booting a 5B from SD or eMMC module

AFAICT neither log shows anything unusual

I would suggest using the AMLGX .tar file in my testing share as this is running a newer kernel (6.17.4 not 6.16-rc3) and the newer Kodi version also has bugfixes. If you're going to use the TX3 device tree you should stop/disable/mask 'display.service' as this is started to drive the VFD display which your box doesn't have.