Posts by chewitt

Quote from Wetek_D

Really dont know how to do the "dmesg | paste" sorry.

You managed to type "dmesg" and hit enter. All you had to do was type "dmesg | paste" and hit enter.

[ 1.543265] mmc1: Card stuck being busy! __mmc_poll_for_busy
[ 1.544665] mmc1: Failed to initialize a non-removable card

The eMMC storage fails to init ^ and thus isn't visible to the OS, so cannot be addressed. No idea what the underlying issue is, but normally the issue with Android boxes (not specifically WP2) is the chips go bad and throw errors. On the upside, it's failed but still allows SD card boot, which is better than starting to boot and not being able to continue (which can also happen).

The WP2 "board" image you are using cannot boot with the factory Android u-boot on EMMC, so either you wiped/zero'd EMMC to use the image, or the EMMC chips have failed which means the OS cannot detect Android u-boot; thus allowing it to boot upstream u-boot from the SD card.

I'd guess the EMMC chips have gone bad. Share the URL from "dmesg | paste" and we can probably confirm.

RPi4/5 have a single i2s audio interface input, and a single audio driver that supports multiple cards, each with an HDMI connector, and the driver can route audio to either or both cards. The labelling is correct and clear; but alsa is one of the Linux "dark arts" as the terminology (and topology) of things is particularly challenging to understand.

Merged.

Quote from rosede

Any suggestions?

RPi boards simply have rubbish wireless. Use Ethernet. Use an WiFi bridge device that presents Ethernet. Use external dongles with a proper antenna. In short, do anything except try to make the internal WiFi work.

I'm not aware of any project staff that use Chromeboxes these days. Have you looked at the MrChromebox site?

Are there any specific errors with the update process?

Quote from Da Flex

According to aplay output, you've connected both RPi4 HDMI ports. Unplug HDMI-1.

Nope. The aplay -l command does not show connected state, so it is not showing something on HDMI-A-0 or HDMI-A-1 ports.

Here's the output from my RPi5 which 1000% only has a single connection on HDMI-A-0:

RPi5:~ # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

PLEASE stop guessing at answers.

Remove all the config.txt changes (or create a new/clean SD card) and connect the HDMI cable to a different HDMI port on the TV and see if that works. I'd guess no, in which case you need to replace the Type-C to Type-A adapters with a proper Type-C to Type-A cable (no adapters). Adapters are often designed for use with desktop monitors which have no speakers, and thus the HDMI chips used inside them can omit wiring or support for audio to create a cheaper product. I can't 100% guarantee that's the issue, but from experience it's more likely to be something physical like that than anything in software.

S905X and S905W are ARMv8 chips but it's common to see 64-bit kernel and 32-bit userspace on Android devices. The older LE11 (arm) image uses the same combo. LE12 and newer now run 64-bit kernel and 64-bit userspace (aarch64). The userspace change is not the reason why the older image boots and the newer one doesn't; it will be something lower level, and the only real way to understand what is or is-not happening is to see the initial u-boot and kernel boot stages via the serial UART log. That requires you to have a USB UART adapter and the UART pins to be physically on the board to connect to - the pads will be there, but cheap boxes often need the pins soldering and they were omitted to reduce manufacturing cost.

Use an official LE13 nightly or image from my test share https://chewitt.libreelec.tv/testing/ as that's the active codebase for dev work. The S905X board should boot with the p212 dtb file in the "box" image. The S905W board should boot with the p281 or Tanix TX3 mini dtb files.

There are MXQ boxes from Amlogic, Allwinner, and Rockchip and that photo doesn't enlighten us (although the 45 degree rotation on the chip makes Amlogic unlikely). So before we go any further, we'd need to understand the specific chip on the board, and ideally see a boot log from the original vendor OS full of driver information.

Quote from lipo_pan

So i would like to ask if the support of output to both hdmi is supported out of the box or not?

RPi4/5 hardware supports use of both HDMI outputs on a conventional distro that uses X11 or Wayland. In that scenario Kodi runs as a full-screen app and you can select the single display to use, but Kodi does not support dual-output (mirrored output) and AFAIK this is true for all OS, not just Linux. In LE, Kodi runs 'on the framebuffer' with no window manager so we only support output to a single display device. TL/DR: Not possible, you need to use an external splitter.

Fix is merged .. the add-on should update in the next 24h

The majority of reports are from RPi boards but that simply reflects the demographics of a project where 80% of all users have an RPi board. The issue is probably about radio/wireless features in the network and appears to be influenced by signal strength.

It's been flagged to upstream maintainers who are keen to help resolve the issue. Debug logs from ConnMan and IWD and 'iwmon' output when the issue occurs would be useful.

Quote from atirage21

Newer chips as S922x dont have HW acceleration with panfrost.

On ARM boards hardware video acceleration has nothing to do with the GPU, and the difference between OpenGLES 3.1 and 3.2 is frankly not important for LE/Kodi use. There is simply no good reason for LE to use a proprietary closed-source blob that requires maintenance effort over an open-source in-kernel option that requires zero effort. Abandoning libmali once lima/panfrost were viable was a no-brainer (and smart) move for the project, hence we've done it. You're welcome to disagree of course (free world and all that) but your view is firmly in the minority around here.

Thanks. The log omits most of the early boot, but there's an ID clue about the Ethernet device and that allowed me to dredge up some older threads in the LE/CE forums. It seems to have a problem ZTE chip and I'm not sure support for this has ever been fully resolved, but it gives me some ideas to test. I'm away for a few days but will have a look a custom device-tree later next week.

 0.520527@2] eth0: PHY ID 03815c11 at 1 IRQ POLL (stmmac-0:01) active

^ that's the important bit

Stop Kodi on the target device and then copy the sources.xml/passwords.xml files over from /storage/.kodi/userdata and DB files from /storage/.kodi/userdata/Databases and then restart Kodi on the target. Kodi will detect the DB files and migrate the content into new DB files versioned for the current release. Export/Import is .. something I've never used.

I found a patch for the Xtreamer Ultra2 audio problem. I've run into some minor issues that I suspect are simply down to nouveau not being great great quality. It chokes on Tvheadend streams that are H264/1080p and VDPAU decoded, and I've had a couple of crashes that aren't explained (or seen on other devices). Anyway.. time for some downtime.

Quote from atirage21

Why was not updated driver from r16 (r23) to r51 for mali ?

Panfrost made mali-bifrost irrelevant for LE images. The upstream LE repo is archived: https://github.com/LibreELEC/mali-bifrost