Posts by chewitt

Quote from _emanuel_

@chewitt my update for the dreambox patches.

Yes, this is the same change that I made (but didn't share). Nice to know that it works.

Quote from PhoenixBG

There is also a problem with SSH. When trying to connect it shows an error:

The logs show this endlessly repeating:

Dec 11 16:06:02 LibreELEC-Penka systemd[1]: Starting sshd.service...

Dec 11 16:06:02 LibreELEC-Penka ssh-keygen[5065]: ssh-keygen: generating new host keys: RSA Could not save your private key in /storage/.cache/ssh/ssh_host_rsa_key.XXXXl8cxAN: No such file or directory

Dec 11 16:06:02 LibreELEC-Penka ssh-keygen[5065]: ssh-keygen: generating new host keys: ECDSA Could not save your private key in /storage/.cache/ssh/ssh_host_ecdsa_key.XXXXl7zlJv: No such file or directory

Dec 11 16:06:02 LibreELEC-Penka ssh-keygen[5065]: ssh-keygen: generating new host keys: ED25519 Could not save your private key in /storage/.cache/ssh/ssh_host_ed25519_key.XXXXAdmsHi: No such file or directory

The /storage/.cache/ssh directory should be created on first boot automatically so I've no idea how that can happen.

NB: I've not made any changes to Ethernet support in the 6.0.x kernel but perhaps there are general cleanups that improve things.

rmmod r8712u
insmod /usr/lib/kernel-overlays/base/lib/modules/6.1.0-rc8/kernel/drivers/staging/rtl8712/r8712u.ko debug=0x1416

Mind the line wrap ^ above; remove and reinsert the driver with a debug option and then see if anything more was printed to dmesg? - If yes, run "dmesg | paste" and share the URL. If nothing.. I'm out of ideas, other than removing the staging driver and digging up an older vendor driver. The TODO file in staging points to https://github.com/chunkeey/rtl8192su as an alternative; you can probably cp -R an existing realtek driver package.mk and swap the URLs/GitHash details to build it; if it builds.

rellla The plumbing for hardware deinterlace in FFMpeg under V4L2 has been figured out (for RPi, and similar works with other devices) but right now there is no support for the hardware deinterlace IP on Amlogic SoCs in Linux, so FFMpeg will fall back to software (Yadif or Bob, I forget which) sampling. It's watchable for normal media but anything sporting with faster panning shots isn't so great. I'd pay someone to write the driver code if I could find someone to pay..

DVI ports normally present 'Monitor' resolutions not 'TV' resolutions. No HDMI ports? - What resolutions do you think the TV supports?

Your box is running an unofficial OS image created by someone called "surkovalex" under contract with Eminent. The sources for the OS are posted here https://github.com/Eminent-Online/ although it's years since I bothered to look at what changes have been made (and I don't plan to start now). In short; we know nothing about Eminent boxes and we don't provide updated images for them. That said, you may be able to use the dtech 9.2.8 release which still uses the old vendor kernel and fixes a few things. If you need a newer Kodi version and aren't too demanding with codecs there is also an LE11 nightly AMLGX image which runs reasonably well on an S905X device; there are quite a few other S905X box devices based on the Amlogic reference design so you can probably find a device-tree file to use and get things working.

If you are trying to boot an LE 9.2.8 image on a recent RPi4 this will not boot/work as the (older) firmware in the LE 9.2.8 RPi4 image does not support the (newer) hardware in recent RPi4 models. You will need to use LE10.x or LE11.x nightlies.

So use LE 10.0.4, connect HDMI and Ethernet only, test again. If you see problems still, remove "quiet" from boot params in cmdline.txt and then look for errors on-screen. The failure to get time hints at an issue with NTP in your network (or lack of Ethernet) but this should not be fatal, the NTP check should timeout and boot should continue.

Is the drive powered from a separate PSU or the RPi? .. If powered from the RPi, connect it to a powered USB hub and test again.

LE11 onwards uses iwd not wpa_supplicant, so considering that LE10 is basically a dead codebase now (one final update will come for K19.5, but we aren't investigating and tinkering with anything else in the OS) .. test nightlies.

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