If the sources are in a git tree edit the file with the changes then either commit the changes and run "git format-patch HEAD~1" or without committing do "git diff > linux-force-yuv.patch" .. either way gets you a diff patch with the correct paths.
Posts by chewitt
-
-
-
Are the modules for Wifi/BT/Lan generally included?
Everything here is included https://github.com/LibreELEC/brcmfmac_sdio-firmware - and if whatever AP6256 is? is not there, it can be added. You can also follow https://wiki.libreelec.tv/how-to/add-firmware to fix missing firmware yourself while waiting for the embedded firmware to be updated (after you point us to the source).
NB: Broadcom drivers are enabled. Realtek LAN modules are enabled (once in a while some vendor comes up with some other weird Ethernet arrangement, but that's rare).
-
-
The OE patch added a driver for Spinelplus IR receivers, but it requires a bunch of USB ID's to be patched into common kernel files that are frequently updated, and because the original author never bothered to upstream the driver, the downstream patch needed constant rebasing against kernel changes. This task quickly becomes a problem chore, so the patch was eventually dropped.
In the absence of a proper kernel driver you can fall back to using lirc, which still exists in LE but (IIRC) lircd is no longer started unless /storage/.config/lircd.conf exists. Step 2 and Step 4 from the article you linked should still be valid.
-
-
This is forum for Linux not a forum for Android ROMs. Use 4pda or similar that cares for Android things.
-
Output is HDMI *or* Composite, never both. Composite refresh-rates are defined in common kernel code (not Amlogic driver code) and implement the broadcast specs for NTSC or PAL, neither of which use 59.94 output.
Kodi does not support dynamic reconfiguration of itself each time you switch display device (although it is mildly tolerant of changes within the same display techology, e.g. one HDMI device to another HDMI device). So install the device to the screen that you intend to use and the leave it in a working state. If you keep switching, expect it to keep breaking.
If you connect Ethernet the default route will switch to Ethernet. It's possible to change ConnMan behaviours by copying the config file in /etc/connman/main.conf to /storate/.config/connman_main.conf and changing PreferredTechnologies = ethernet,wifi to PreferredTechnologies = wifi,ethernet then connecting Ethernet won't steal the default route.
I've no idea about analogue audio output. The p201 device-tree file does not implement support for analogue audio, but that's not unusual as on most GXBB (S905) designs the DAC is hardwired (always on) so there's nothing to enable or control from software other than the global (master) volume level. If your box is different and has a controllable DAC chip it will require the driver to be enabled in the kernel config and the DAC chip to be described in device-tree; and then you'll need to script post-boot changes to the default mixer settings (which are configured on boot for HDMI output) to switch i2s output to the DAC chip.
NB: If you want something cheap that better supports Composite output, my suggestion would be to use an RPi board. Composite on Amlogic hardware isn't something that's ever been tested by me (as I have nothing that accepts Composite input) so our images are oriented towards HDMI usage and you're probably going to fight the OS at every turn.
LE does not implement boot menu's so no idea what you're talking about there.
-
No idea. I've always edited /storage/.kodi/userdata/sources.xml over SSH to type the info in with a keyboard as it's much easier than the so-called "easy" method of browsing the network and typing passwords using a remote control.
-
Our crystal ball isn't working today so you might need to demonstrate the problem and share logs.
-
If I understand it correctly, than these files may differ
There is no 'may differ' the kernels are different so the device-tree descriptions of hardware are different. There is enough common heritage that you can probably get something to boot using a device-tree file from the latest downstream Rockchip kernel (Linux 6.6 IIRC) but differences mean specific things are not described correctly and that results in those things either not existing or not working correctly.
If you edit extlinux.conf on the SD card and change FDTDIR / to FDT /rockchip/rk3588s-orangepi-5.dtb u-boot will not autoselect the dtb file to use and will boot that specific device-tree file. Experiment with the Opi 5 and 5b files (which are also RK3588S) and see if either of them (or perhaps other RK3588S boards) work better. Things like hardware decode should be enabled for every upstream board. Things like Networking might be wired up differently on different boards.
-
The patch was authored for Linux 6.6.22 and the master branch currently targets Linux 6.17.8; so the kernel code the patch targets has changed and the patch cannot be applied.
-
The LE image for Rock4D is designed for SD card or detachable eMMC module (written like an SD card) boot with a Radxa Rock 4D board. The image is not the correct "img" format for use with Rockchip eMMC flashing tools.
NB: I have no interest in trying to support Android set-top box hardware with these images.
-
Code
chewitt@toolbox:~/linux.chewitt$ ls -l arch/arm64/boot/dts/rockchip/rk3588*orange*.dts -rw-rw-r-- 1 1851 Oct 12 11:06 arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts -rw-rw-r-- 1 7531 Dec 2 13:39 arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts -rw-rw-r-- 1 1398 Oct 12 11:06 arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-ultra.dts -rw-rw-r-- 1 681 Nov 27 05:31 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts -rw-rw-r-- 1 1018 Dec 2 13:39 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dtsTweety The file list above ^ is from Linux 6.18.0 (released this week) and I don't see an OrangePi 5 "Pro" device-tree file to make an image from. It's best that you contact Xunlong and get them to submit patches to add the board upstream; then I will be happy to pick/backport them for testing. Or if you can point me towards patches from another distro targetting a recent upstream kernel (not the downstream vendor kernel) I can take a look at them.
Hardware decode works fine here with the upstream RK3588(S) boards I have (none of them OrangePi 5 variants) so I can only guess that whatever dts file you have tried to use (which you haven't identified) either has nodes missing or is for the downstream kernel (which uses different nodes) .. but since both of those scenarios are "not using the correct dts for the board" .. YMMV

Networking is the same. Works fine here using the correct dts for the board(s) I'm testing. Time to learn how to read schematics

-
Add that ^ to kernel params in cmdline.txt and see if forcing the initial DRM connector state to 1080p changes anything?
LE12.2 has a newer kernel than LE12.0 so the DRM layer can behave differently (even if ports/cables didn't change). RPi5 sometimes defaults to using 4K modes the TV doesn't like.
-
This is going to be a Kodi bug (not an LE specific bug) so it should be reported upstream via Kodi GitHub. Take care to follow the issue submission template; provide a full debug log that demonstrates success and then failure, and steps to reproduce.
-
Code
dtb_name=/amlogic/meson-gxbb-p201.dtb bootargs=boot=LABEL=LIBREELEC disk=LABEL=STORAGE quiet systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0 video=Composite-1:720x576@50ie^ the second and third lines are a single line (the forum wraps it). The file needs to be edited with something that respects Linux file endings. In the past Notepad.exe would mangle the file with Windows line endings and boot would break, so you'd need to use a text editor like Notepad++ to avoid the problem. I'm not sure if newer Windows OS learned not to do that, or if that's your issue..
NB: The video= content only sets the initial DRM connector state. Kodi can then mode switch to something else once running. Kodi only outputs progressive, never interlaced; hence you will never see interlaced modes listed/available for selection.
-
Did I miss something or is the TVH PVR Client vanished from nightly Generic builds?
This disagrees with you: https://addons.libreelec.tv/12.80.4/Generic/x86_64/pvr.hts/
Have you tried force-refreshing the LE repo?