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.
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/USBDRIVEThis ^ 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.
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.
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.
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.
Using mpv-libplacebo as the playback backbone of Kodi would be a gamechanger imho
Kodi on Linux is a big fancy (and deeply integrated) wrapper around libav/ffmpeg so any idea using mpv is a non-starter. It's also not required since libplacebo can be integrated with ffmpeg, as mpv (which is based on libav/ffmpeg) does.
However, libplacebo is intended for x86_64 architecture devices using OpenGL/Vulkan, which doesn't align with ARM SoC boards that use OpenGLES; althrough really it's about the formats used and where to implement the shaders required. The zero-copy pipeline we use with GBM also poses a challenge as it assumes you take a raw decoded frame and move it through the pipeline to the output stages without copying (or transforming it in software, which inherently requires copying). Hence ARM SoC's handle transformation in hardware during decoding (while extracting the raw frame) or in hardware using a image post-processor in the output stages. As mentioned before, RPi5 is lacking those hardware functions.
NB: Tiben20's current experiments are targetting Windows.
wifi on a Radxa Zero 3w appears to not be recognized
The initial dev samples of the Zero3W had a Broadcom WiFi5 chip. The release versions were 'upgraded' to WiFi6 with an AIC8800 chip that has no drivers in the upstream kernel, which is probably why the WiFi/BT nodes required to use a driver that doesn't exist have not been added to the device-tree file.
Radxa have an AIC8800 driver in their repo: https://github.com/radxa-pkg/aic8800 but LE has no interest to add downstream vendor drivers to codebase unless there is a visible/known plan to upstream them (so we can drop them once upstream).
Please push device-tree changes to a public git repo somewhere or share a patch file here so I can see the changes required.
NB: I'm currently helping with the upstreaming of https://github.com/jefflessard/linux/tree/tm16xx which adds support for the VFD displays in most Android STB to the mainline kernel. Also see https://github.com/jefflessard/tm…ree/v4-feedback. The kernel driver and userspace packaging is still undergoing some changes, but works well.
Please ignore. It was late (for me) and I've gotten confused with another thread where the user is looking for drivers and I added a patch. There are no changes in the GBM image in my share, it was for testing something else.
treedav I've picked the Armbian patch that Yasai-san flagged, and pushed an updated image to my test share. On reboot the card should now be detected, but firmware will be missing. Check the system log for errors and filenames.
See https://wiki.libreelec.tv/how-to/add-firmware for instructions on manually adding firmware. This repo has firmware files with a blind guess at the needed filenames: https://github.com/chewitt/brcmfm…re/tree/ap6275p
https://forum.armbian.com/topic/36744-or…dComment-214649 suggests this might not be enough, but best to try. If it does work I can send the patch upstream and add the firmware to our collection. Please share the journal log, e.g. journalctl | paste and share the URL.
AxelSat update to the image I posted to my testing share and then share the system log .. let's see what happens
