Posts by chewitt

  • Unofficial LE for RK356x RK3328\RK3399 RK3588(s) RK3576

    Quote from Tweety

    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.

  • Unofficial LE for RK356x RK3328\RK3399 RK3588(s) RK3576

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

    Tweety 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 /shrug

    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 :)

  • [S905] WiFi issues (w/ test builds)

    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.

  • [S905] WiFi issues (w/ test builds)

    Thanks for confirming and sharing the log. I've sent the wifi firmware patch upstream: https://patchwork.kernel.org/project/linux-…[email protected]/

    For other Q's:

    1. If using Composite output the DRM connector cannot auto-detect the presence of a display (or the display type) and you probably need to force ouput, e.g. for NTSC add video=Composite-1:720x480@60ie and for PAL add video=Composite-1:720x576@50ie to boot params in uEnv.ini on the SD card. Note that the default Estuary skin in Kodi is designed for a minimum 720p screen so when used with something smaller navigation can be challenging.

    2. LE does not support boot/run from eMMC with Android boxes: https://wiki.libreelec.tv/hardware/amlogic#installtointernal

    3. No, because the box implements rmii (internal-phy) not rgmii (external-phy) so in the upstream kernel p201 is the sole correct dtb to use. I've no idea why the upstream and downstream numbering for GXBB development boards is different, but it is.

    NB: ethmactool "errors" are harmless and can be ignored, it's simply a boot-time script that ensures the Ethernet MAC is unique

  • [S905] WiFi issues (w/ test builds)

    It looks like upstream linux-firmware moved the mt7601u.bin files to the mediatek subdirectory in https://git.kernel.org/pub/scm/linux/…35d3cf5bb8a8fcb so a patch is needed to check the new location (and the old one, to preserve compatibility).

    I've written/added that patch now: https://github.com/chewitt/linux/…0fa9514c1bccaed so go download the AMLGX image from my test share again and the MT7601u chip should now find the firmware. NB: Only test the AMLGX image with the p201 dtb - anything else is wasted effort and noise.

  • LE 12.2.1 TVHeadEnd 4.3 no picture, only sound for SD channels only

    I don't see anything that looks obviously wrong. The channel is opened and you can see ffmpeg parsing content. Two audio streams are found; one is mpeg2audio which I'd guess is stereo, and one is ac3 which I'd guess has 5.1 audio, which is selected alongside the H264 video content.

    Disabling VAAPI changes the process flow inside Kodi, although I'd have to go look at code to understand more. I'm wondering what differences might exist/show in the logs as a first step. Please share some additional debug logs (separate logs/pastes if possible, as these are easier to search).

    • Show an SD channel with VAAPI disabled
    • Show an HD channel being opened

    NB: LE did bump the Tvheadend version last week https://github.com/LibreELEC/LibreELEC.tv/pull/10719 but the list of changes in the update are not particularly interesting (compile fixes, translation updates, etc.). There are also ffmpeg changes to improve the transcoding capabilities (mentions of VAAPI here, but this is encoding not decoding) so I'm not immediately seeing a connection to the problem reported.

  • Flirc remote not working

    I don't see the errors reading firmware/version that you do when running flirc_util, e.g.

    I'd suggest contacting flirc support as they know their hardware better than we do.

  • [S905] WiFi issues (w/ test builds)

    The upstream kernel p200 dtb is for devices using external-phy (rgmii) with Gbit Ethernet and the chip on reg=3 of the MDIO bus.

    The upstream kernel p201 dtb is for devices using internal-phy (rmii) with 10/100 Ethernet.

    The downstream kernel gxbb_p200_1G_100M_RealtekWiFi file uses rmii so p201 upstream is the correct one to use.

    In the upstream kernel both p200 and p201 have identical SDIO (WiFi) configuration inherited from the p20x.dtsi. This is set to probe SDIO reg=1 and although it is technically possible to have other SDIO reg assigments on the bus, I have never seen any Amlogic device with any SDIO module use anything other that reg=1, so the p201 dtb should result in SDIO probing and loading of the WiFi driver in the image. I'm not seeing any SDIO probing so you either share a log from the CE image to prove something exists, or we believe the upstream kernel logs that show a MediaTek MT7601U chip connected to the USB bus. Assuming this is not an external USB dongle; the chip is internally wired. If true it will be the first time I see that specific chip used in an Amlogic box, but it's a cost-engineered (cheap) internal-phy box with 10/100 Ethernet so using a cheap USB chipset internally is completely plausible.