Posts by chewitt

_emanuel_ I put the wrong value in the dtb .. will share another image. It looks like recent kernels have an issue with emmc on some (or all) G12+ devices which needs looking into, but you can steal the dtb to use with a nightly.

Staging means the driver is still in development (this one for many years) so the driver code is located in a specific separate area of the kernel tree (filesystem) but otherwise the process for enabling the module is the same as any other; uncomment and setting CONFIG_R8712U=m or =y should be the only thing required to build the driver. In LE buildystem, make the change to https://github.com/LibreELEC/Libr…ch64.conf#L4917 then build the image again; the kernel defconfig change will be detected and only the kernel (and any packages depending on it) will be rebuilt so it's normally quick to respin the image. I can see that the USB IDs for your card are present https://cateee.net/lkddb/web-lkddb/R8712U.html so in theory it should probe and be active automatically. If it doesn't, there's an issue to be investigated.

Tailscale would not be integrated into the interfaces managed by ConnMan so when the VPN interface is brought up, no routes will be created on the host to route traffic from an AP tethered device over the Tailscale tunnel. That's not particularly hard to solve.

Kodi release dates have always been a rather elastic concept

_emanuel_ this image https://chewitt.libreelec.tv/testing/LibreE…85.0-box.img.gz has "meson-g12b-dreambox-one.dtb" included with a change to the SDIO reset GPIO; otherwise it should be similar to the GT-King dtb. Any difference?

_emanuel_ The W400 dtsi that GT-King dts consumes from sets the SDIO reset GPIO to GPIOX_6 (low):

linux/meson-g12b-w400.dtsi at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

but the Dreambox One dts in your GitHub repo sets the SDIO reset to GPIOA_11 (high) and there are pwm things being defined below:

linux-meson64/dreamone.dts at master · emanuel4you/linux-meson64

linux meson64. Contribute to emanuel4you/linux-meson64 development by creating an account on GitHub.

github.com

From pics I've seen the Dreambox uses a custom PCB, so it's probably not a reference design clone like Android boxes, although so much of the core peripherals are on the SoC (and thus have common config) that a box dts can boot the board. If the reset pins for SDIO aren't being driven, this would explain why there's no attempt to probe the bus in dmesg. The BT part is physically on the same chip, but driven separately so working BT and non-working SDIO is normal (possible).

I'm not completely sure how to read the pwm changes and bits in the vendor kernel dts, but there are differences.

LABEL LibreELEC
  LINUX /KERNEL
  FDT /rk3399-rock-pi-4b.dtb
  APPEND boot=UUID=0503-4902 disk=UUID=8ff85d86-0886-4367-affc-e7e92877481a quiet console=uart8250,mmio32,0xff1a0000 console=tty0 coherent_pool=2M cec.debounce_ms=5000 drm.edid_firmware=HDMI-A-1:edid/edid-HDMI-A-1.bin video=HDMI-A-1:D

^ edit /flash/extlinux/extlinux.conf and append it to the APPEND line

The challenge with alsa plugins is they need to be built and baked-into the image to use, and then users need to create custom alsa configs to use them. Creating alsa configs is, err, one of the Linux 'dark arts' and where most people will come unstuck.

As a general rule support for ARM boards is best on the latest kernel so LibreComputer are probably bumping to something newer than the stock 5.15 one. It means the driver in the image is more likely to be the staging driver we're interested to prove, but there's only one way to really find out.

https://wiki.libreelec.tv/development-1/build-basics has some instructions for building. There are build-in-container options in the wiki too if that's easier on your current setup. It's quite a simple process.

The intiial issue with that add-on will be that LE only uses Pulse audio for streaming output to BlueTooth speakers, we use alsa for all other output. It's possible to reconfigure LE to use Pulse though. The wiki describes some other configurations, see https://wiki.libreelec.tv/configuration/pulseaudio - not specifically your requirements, but at least explains what the config files and required touch points are to make an alternative configuration. There are probably threads in this forum about using Pulse too.

The kernel in the Ubuntu 22.04 VMs that I have running is Linux 5.15.x and although I haven't checked, I would expect the distro to package the Realtek vendor drivers. We avoid those because they are a pain in the arse to maintain over time; they break with every major kernel bump (something we do more often than most distros) and need constant patching. Ubuntu has more people contributing to their sources and puts up with crap like that.

The kernel in LE master (nightlies) is currently Linux 6.0.x which has a staging (testing/development) driver for that NIC, but the module is not enabled in our kernel defconfig so the driver will not be built and thus the card should not work in our nightlies.

See: https://github.com/LibreELEC/Libr…ch64.conf#L4917

The kernel version and defconfig used in balbes150 images is unknown to me and these days I have no idea where Oleg publishes sources to check. It's possible his images have the module enabled and it's possible the staging-quality driver doesn't work (or work great). It's possible he has added the out-of-tree vendor driver

If you're confident with Debian etc. perhaps self-build your own LE master nightly image with the staging driver enabled. It might then be missing firwmware, but dmesg will reveal which file you need to pick from the upstream linux-firmware repo to test/prove it. That file might be the same filename as older vendor firmware, but there's probably alignment between driver and specific firmware versions.

The single log that you shared only shows a booting kernel where a driver loads without errors - it's not hinting there's a problem.

NB: Please keep the convo in this thread instead of scatter posting over several.

Quote from HiassofT

If and when Kodi 19.5 will finally be released and what fixes it will contain is a question only kodi folks can answer

So i'm telling you (as a Team Kodi person) that the original intention was always to make the K19.5 release immediately before K20. The dates for K19.5 on GitHub will be pushed back as/when someone remembers to move them until roughly that happens.

The original plan was to make a final roll-up of changes and ship K19.5 shortly before K20 release (think days, not month).

Then what is the feature request?

Run "dmesg | paste" and share the URL generated

The "not too expensive" requirement is a challenge these days; any recent NUC device or x86_64 equivalent with an integrated Intel GPU would be fine. Perhaps just keep an eye on https://rpilocator.com/? for stocks appearing somewhere.

Quote from patric

Maybe LibreELEC should add a default config for BT remotes so c0041 gets mapped "enter"?

It's not possible (and wrong) to assume all devices have the same mapping. That said, I'll have a scout on the interwebs for other distro's lists of BT remotes and see if we can increase coverage in our default/embedded list.