Posts by chewitt

There is no upstream driver and no current attempt to author an upstreamable driver that I can see.

This appears to be the most widely used driver source that I can see: https://github.com/fifteenhex/xradio and this probably makes it the 'least worst' to use (the repo README is honest). This chipset has quite a reputation for being rubbish once you start looking-for and finding information on it.

LE has zero interest in adding out-of-tree drivers with no upstream plan to the buildsystem, but a self-built image can probably be done. I spotted some notes here: RE: How helpful will this be to getting LibreELEC on allwinner android boxes? and the zip file posted there contains some examples of the kernel device-tree changes that would be needed alongside the kernel driver itself. There are other threads that mention XR819 but they look to be mostly users asking for drivers and being told that it's not supported.

Unless you like the development challenge (with the likelihood of a poor experience outcome even if successful) I'd probably just get myself a USB wifi dongle or a USB-powered Ethernet/WiFi bridge dongle and not go down the self-built image route.

If you do, the Realtek out-of-tree drivers found in older LE images (LE11 for example) are probably a good starting point for cribbing the format for a simple buildsystem package that compiles the driver.

I pushed updated images for all Rockchip hardware to my test share. Older hardware now includes the kernel fixes recently made for LE12.2 images and a bump to 6.16.4. Newer hardware has additional realtek NIC firmware(s) to silence missing firmware messages noticed in some of the logs recently shared. Kernel for newer hardware is bumped to 6.17-rc5 .. no media capability changes.

The audio glitch is likely the outcome of a lack of bandwidth on the connection as reducing bits-per-pixel (bpc) from 12-bit to 10-bit will reduce bandwidth consumed by video and create headroom for audio; and this appears to work around the issue.

Colourspace and Colourdepth are different things. There is also a distinction between RGB and YUV output and these both depend on the HDMI capabilities of the hardware (including any inline converters) and the connected TV and/or AVR.

The DP cable will be mitigating the audio glitch as it forced colourdepth to 8-bit. Combined with BT2020 colourspace this is still valid for HDR, but 10-bit depth would be preferrable to 8-bit as the latter normally results in visible banding due to the lower number of colours available.

Quote from Elicity

Which one do you recommend:

I recommend you experiment and figure out if one of them boots with the device-tree file that Armbian are using. Then (most important) you keep quiet if there are any issues, because it's a hack. I'll happily pick support for any new boards to the patchset, but it's a hard requirement to see the patches on a mailing list first.

The lsof command is a snapshot point in time, not a continuous historical view. So if the process accesing the drives is something that runs/stops/runs/stops you might need to run it a few times to catch/observe the process that accesses the drives.

NB: I'd expect something like 5-seconds shutdown to be ineffective. Try using a longer value like 30/60/90 seconds.

Quote from ApexDE

it didn't show up under LibreElec 12.02 Updates/Updatechannel.

Intentional, because it's not a 12.0.x release, and there are breaking changes for some hardware types.

hephooey The vendor kernel required a bunch of intrusive workarounds to make 4K H264 work on GXBB hardware and to keep the code cleaner this was never replicated into the upstream driver, so GXBB is intentionally capped at 1080p. GXL and onward can handle 4K H264 without the workarounds.

Original developer comment: https://github.com/Elyotna/linux/…mment-491039526

You are already talking to the developer: https://github.com/aassif/pvr.freebox/issues/118

Continue there. He knows more than we do about the add-on and how it works.

See https://github.com/LibreELEC/release-scripts

I've pushed some updated AMLGX images to my test share (first time in a while) which have the 'being upstreamed' VFD driver working in a near final state now. There's not much else interesting aside from a bump to Linux 6.16.5. No changes in any of the media capabilities.

lsof | grep /media/USBDRIVE

This ^ will tell you the processes that are interacting with the disk (at the time you run the command). It might just show Kodi which is not helpful, but might also show you something else on the system that's keeping it awake.

Quote from RChadwick

Is there a way to configure these files to be put on the 8TB drive instead? Or can I fix this by changing partition sizes? Something else? in System Information, it shows mmcblk1p2 is 28G, with 28G being used 100%.

The initial image that you wrote to the SD card has 512MB for /flash (boot) files and 32MB for /storage; the second partition should be removed and resized to 100% (32GB) on first boot. If you have run out of space, either something has dumped a ton of data to the SD card and filled 32GB up, or perhaps the remove/resize didn't happen and you've filled up 32MB not 32GB?

Boot params on the SD card in extlinux/extlinux.conf show boot=UUID=<string> disk=UUID=<string> .. if you check the UUID for the partition on the USB drive using blkid you can change disk=UUID=<string> to use that UUID and on boot it should use the USB drive for /storage and you'll start with a clean Kodi instance that you can move config over to. You can also mount using disk labels, e.g. boot=LABEL=LIBREELEC disk=LABEL=MYDRIVE assuming partitions are labelled or boot=/dev/mmcblk1p1 disk=/dev/sda1 style params. Note that you will need to use a Linux filesystem on the USB drive, e.g. EXT4, else the ssh daemon will fail to start since it depends on Linux filesystem permissions, and non-Linux filesystems (NTFS, exFAT) don't support Linux permissions.

In theory the SD card image can be written direct to the USB drive and it should boot from that too; although I have fuzzy recall that the Amlogic bootrom only checks for bootable USB drives in specific ports, e.g. the OTG port.

You can trigger the script direct from udev rules. There's no need for the systemd mount file.

Quote from Roomen

How do I enable drivers in the kernel configuration?

Edit and save the file.

NB: I don't want to be rude, but if you need this level of Linux skills spoon-feeding, our complex embedded-style packaging means we are not the distribution you are looking for. Something like Ubuntu will be much easier for a beginner.

Quote from jim_p

Is there a chance to add b43? It may work better than debian's b43

It was already evaluated and found to be as rubbish as the last time we looked; nothing improved in more than a decade. Except for the occasional 'treewide' change to fix or mod something it's received no maintenance in years and is abandoned. I'm genuinely surprised that it hasn't been dropped from the kernel in a dead-code cleanup.

There are lots of LE13 nightlies on the server. I'm less sure about older Tvheadend versions but there's probably a few.

If you can roll back and experiment to prove software caused the change we can investigate. If there's no correlation, it's something else, i.e. environmental.

The kernel defconfig is located at projects/Generic/linux/linux.x86_64.conf not under the Linux package folder.