Posts by chewitt

Images for older boards in my test share are updated to Linux 6.16.4 and now include fixes for 10-bit format selection that were broken in semi-recent kernel bumps.

Quote from Elicity

I could not find a case for the Rock-4D, does it fit a PI-case by any chance?

No idea, I have no RPi cases kicking around at the moment (other than RPi5 cases which definitely aren't the same).

Quote from Roomen

If your colleagues can help us, we will be very grateful!!!

I have friends in the project, but no colleagues; because we are not a company, there is no product, and we do not undertake commerical development or support work. Good luck with the AI suggestions!!!

The brcmfmac driver needs to load a firmware (.bin) and nvram (.txt) file from /usr/lib/firmware/brcm but we have no firmware files for BCM4354 in the AMLGX image. If you find files, add them manually: https://wiki.libreelec.tv/how-to/add-firmware

Most mentions of IP1001M found via Google seem to point back at either unifrequ/ophub device-trees, which look to be a hack job that only partially works, or CE forum threads which fizzle out with the recommendation to avoid X' boxes.

I did also find https://blog.csdn.net/zuiaikg703/article/details/120350194 which (translated) has some hacky changes for an IP1001C variant, but Google AI claims the difference between IP1001C and IP1001M is that C is multi-mode (copper/optical) while M is single-mode (copper). The current ICPLUS PHY kernel driver only implements a relatively basic level of support for registers, so I would assume it was written around the M variant, but AI also flagged some differences in support for Jumbo frames and other items between C and M that I don't see registers being defined for, which leaves scope for unknown defaults that could leave the PHY misconfigured.

One thing I did notice is the current kernel driver does not support the 0x02430d91 hardware identifier that I see mentioned in the unifreq dts, so the MDIO bus will not auto-discover and configure the chip automatically.

This should add the identifier: https://github.com/chewitt/linux/…9d8517b2529ebd4 but no guarantees that helps? You may also need to undo some of the ethernet_phy/mdio hackery from ophub dts files.

The latest AMLGX images in my test share have a kernel with that patch, but not a dts for the X96-max-plus box.

Nothing is impossible, but we don't normally support hardware with those features; they aren't needed on HTPC devices connected to a TV that don't move. So we have no idea what's required, you don't either, and Google searching on "HiGole 2 Pro" mostly finds complaints about being unable to find drivers, no support from the vendor, and it being rubbish hardware that dissapointed and then died. If the screen is mirrored then you definitely need a windowing environment like Wayland or Xorg. Our legacy image has Xorg but you'd need to configure it to use various drivers and how that's done is not documented.

Sorry, but we are quite focussed on HTPC hardware and are not a general purpose OS.

Do the Samsung and Toshiba TV's have similar resolutions/mode capabilities?

If yes, connect the device to the Samsung TV, run "getedid create" and allow it to capture the EDID data. Then shutdown and move to the Toshiba, and the OS will still see itself as connected to the Samsung. This might (or might not) work.

If they don't, e.g. Samsung supports 4K and Toshiba does not, use the whitelist to only allow the 1080 modes to be used.

IAutomatic rotation would require something like a windowing environment to be rotation-aware, but being minimalist LE does not run Kodi under a windowing environment. The same is probably true for the touch driver.

I think you would be better off running Kodi under a conventional distro.

I've resolved the missing audio on RK3328 and RK339 boards and pushed updated images to my share.

Quote from Elicity

Just curious if this also applies to LibreELEC ?

I've been running tests on an RK3576 Rock-4D board. The kernel codebase is still maturing in places but I think this will be a nice sweet-spot for LE use. The boards are less-featured than RK3588, which makes the boards cheaper, but the peripherals that have been omitted are all things that LE has no use for, while the media capabilites are essentially the same.

(ifconfig wlan0 down && ifconfig wlan0 up)&

If you need to do it over the wlan0 connection, don't forget to background the command ^ else the 'up' will fail

This test image has the mxc4005 and goodix_ts drivers (and their dependencies) enabled:

https://chewitt.libreelec.tv/testing/LibreELEC-gbm.x86_64-12.90.1.img.gz

This kind of portable device is not the kind of x86_64 hardware that we normally target so I have no idea if any other config is required to make things work.

ifconfig wlan0 down && ifconfig wlan0 up

That ^ will bounce the wlan0 interface and thus force the interface to be reconfigured.

2025-08-27 17:55:57.951 T:823      info <general>: CAESinkALSA::Initialize - Attempting to open device "default"
2025-08-27 17:55:57.963 T:823      info <general>: CAESinkALSA::Initialize - Opened device "default"

The logs are full of this ^ which indicates trying to open the 'default' audio device which is often/normally mapped to some kind of Analogue audio output.

2025-08-27 17:55:49.327 T:822      info <general>:     Device 3
2025-08-27 17:55:49.327 T:822      info <general>:         m_deviceName      : hdmi:CARD=Audio,DEV=0
2025-08-27 17:55:49.327 T:822      info <general>:         m_displayName     : Intel HDMI/DP LPE Audio
2025-08-27 17:55:49.327 T:822      info <general>:         m_displayNameExtra: TSB 55UHD_LCD_TV on HDMI #0
2025-08-27 17:55:49.327 T:822      info <general>:         m_deviceType      : AE_DEVTYPE_HDMI
2025-08-27 17:55:49.327 T:822      info <general>:         m_channels        : FL, FR, BL, BR, FC, LFE, SL, SR

The device with TSB 55UHD_LCD_TV name looks to be the Toshiba TV (on an HDMI connection).

So, have you selected the correct HDMI device in Kodi audio settings?

There is currently no mainline Linux kernel driver for the YT8601 chipset. There was a submission of patches to add support back in February: https://patchwork.kernel.org/project/netdev…2A&archive=both but there are quite a few comments to be addressed in the v2 series and there has been no v3 submission that I can see since then.

I'd be happy to cherry-pick patches for something that looks like it's nearing a mergeable state (as we can drop them in the near future once merge happens) but the v2 submission looks to be some way off that.

There are also some 'vendor' drivers that can be found on GitHub, but we have no interest in packaging out-of-tree drivers these days (the kernel patches would be preferrable).

I'd suggest a USB Ethernet adapter for now, or use WiFi (assuming the box has that and it works), or returning the box for something that has an upstream supported NIC.

Update to 12.2 or a 13 nightly and use the newer Tvheadend 4.3 release there. Check again.

NB: Please avoid copy/pasting AI content in posts. It's always complete BS.

Images are updated with u-boot 2025.10-rc3 to pull in Kwiboo changes for RK3576 boards. In theory no changes for older boards but you never know.

Quote from kelv

Initial boot of 12.90.1 on the rock-4c-plus looked good however no sound devices were picked up by alsa (13.0-nightly has functional sound).

Please put Kodi in debug mode then reboot and run "pastekodi" and share the URL so I can check for issues.

Quote from PANiCnz

For a RK3399 board how do these images differ from the standard nightly's? More or less features? or much the same?

Either way will give it a go on a Rock 4C+.

There should be no real-world difference as we're still using the same overly-large kernel/u-boot/ffmpeg patchsets. To long-term reduce maintenance effort I've merged all the kernel configs though, so it's possible there are some missing drivers.

Drivers need to be included at image creation/compile time. You cannot install or add them afterwards. If you can tell us the specific kernel modules that need to be enabled, we can add them to future images.