Posts by ozarks

Quote from chewitt

I've pushed revised RK3288/RK3328/RK3399/ RK356X/RK3576/RK3588 images to my test share. The main change is a kernel bump to Linux 7.2 with the latest usable iterations of the many patch series that go into current images. Of particular note: older Rockchip hardware is now using the same kernel as newer hardware since Kwiboo has been reworking old bit-rotten patches that broke and reworked patches are slowly being upstreamed.

However !!! WARNING !!! .. I'm on vacation with zero access to hardware so the images are compile tested only, and a few large G&T's have assisted some of the patch wrangling. What could possibly go wrong?

I'd advise taking a backup of KERNEL/SYSTEM before updating in case I messed things up and you need to roll back. I've not kept up with patches since Linux 6.19 so I'm half expecting some feature differences somewhere if I've missed things. Reports of success or failure (or feature completeness etc.) are appreciated.

Thanks for the images.

I updated from the latest nightly build using the .tar file on my Orange Pi 5 and the update process went smoothly.

YouTube playback was as flawless as it usually is.

When I turned my attention to a list of test files, some of which are common files available on the web I found that some would not play at all, one would seem to play with great delays between frames and some that would result in a black screen, where my TV would lose signal, only to regain it once the file playing in the background finished and returned to the GUI, allowing the file to be played successfully on a repeat play.

So fair to say that that there is some regression but it is not a bad thing to see where we are with the new kernel right now.

Having followed the many updates from collabora in recent months that seem to be bringing the whole picture together more, especially as more and more go upstream, the future might have some light ahead for the RK3588.

In terms of where things stand right now though, experience has taught me that sometimes a fresh install is the way to go, so I will create a fresh one and repeat my testing to see what the state of play is.

I would be disappointed to hear any response from you whilst you are knocking back your few large G&T's in your paradise holiday location.

So enjoy the booze, the other consumables, the relaxation and continue again on the flip side.

I have asked the question over at Armbian and piecing together what I have previously read about the USB-C, which I am hoping will be a universal kind of fix for all RK3588 boards.

I have noted recent entries on the Collarora to do list regarding eDP, USB-C link and the latest entry for DisplayPort controller, which seem linked to me but will seek more clarification on what the defined meanings are in order to identify what I think may be a patch before sinking sending you on a wild goose chase.

That there are other ports to provide the necessary USB I/O connectivity means that use and testing can proceed pro-actively.

Tested for a few hours on my Orange Pi 5 8Gb board.

Works beautifully for the vast amount of 100+ files that threw at it.

VP9 4K does not seem to work correctly. It attempts to play but does not switch to the video playing in the background and as I move my mouse I get a mouse trail. I am able to assess the play button to stop play, so no locking up. With VP9 still on the Collabora list for resolution, I therefore expect this not to work, so not a fault right now.

No hardware acceleration on AV1, which I partially expect based upon comments made on another thread where whilst Collabora have reported AV1 as complete, this turns out to not to be the case.

Everything else plays perfectly in line with the 'basic sanity testing' stated by the OP.

But I can add that I could not find a file outside of VP9 or AV1 that did not play as hoped, including some high bitrate files at up to 400MBps.

YouTube plays perfectly, subject to the VP9 and AV1 caveats mentioned above.

Nice to see CEC present and working.

One note regarding the OP5 that I know is not a direct focus of LibreELEC, which is active on some distros like Armbian but not on others, is the USB-C port, where I sometimes have my mouse, keyboard and controller plugged in via a hub, is inactive. Just for note to other OP5 users so that they can know what to expect from the start. A feature no doubt to come when code is pushed to mainline in future Linux kernel releases.

In short, amazing work that I could not really want more from right now.

No lockups, restarts or erratic behaviour so far.

It will become a daily driver already.

Only faults and improvements to be posted from now on as per the OP's requirements.

Quote from wmasmith

Yeah that looks nothing like the file structure I see. I'll keep trying things. I'll probably fire up a Linux laptop and try from there.

What does your look like?

The general structure should be identical across the spectrum.

Quote from wmasmith

ozarks can you throw your directory listing of / and /boot somewhere for me? I tried using an armbian image that boots on the opi5 to get the u-boot stuff off of it with no luck. I'm obviously missing something.

When you say boot, I'm not sure where you mean. There is no /boot directory that is directly under /.

Quote from wmasmith

SD card. I'm trying some other disk writing utils and card to make sure it's not a hardware or media issue. Thanks for clarifying.

Yes, worth trying other cards. I'm using an old no name class 10 16Gb card.

I used either Rufus or Pi Imager to write it.

Quote from wmasmith

I tried to use the same image you did on my Opi5 and it just hangs at the Opi splash screen. Can you point me to how you got the point of it even booting. I edited the config in the extlinux folder to point at the orangepi5.drtb but it refuses to post Did you start with a different uboot or just the image you posted and modify the config file?

I just used the image posted and the editing of the config file.

Are you booting from UDB drive or MicroSD card?

I am using a card.

Reading through an old thread on the Armbian forum from 2023, titled, [GUIDE] Kodi on Orange Pi 5 with GPU Hardware Acceleration and HDMI Audio, one of the additional options, when enabling enable drm_prem_hw running Kodi under GBM, there was a third option that really opened up the HW decoding performance, called PRIME Render Method where the option "Direct To Plane" enabled a wider array of hardware accelerated video, including 8K.

Within the instructions there was this section

Step 4 (Enable PPAs and install other elements required for GPU hardware acceleration)

At the command line, enter the following commands (highlighted in Blue):

sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa

sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia

sudo apt update

sudo apt full-upgrade

sudo apt install ubuntu-desktop kodi

When prompted on-screen if you wish to use gdm or lightdm, select gdm.

Now this was all relevant to a fairly specific Armbian build using the old 5.1 kernel and unfortunately, the liujianfeng1994 repositories don't work with newer builds.

I don't know whether any of this information could be used to enhance Libreelec builds to allow the selection of the Prime Render Method Direct To Plane.

Quote from chewitt

The issue is known about in the Wayland ecosystem for many years already so I woulnd't hold breath or hope of a solution. NB: It's generally not an issue as Kodi GBM works well, although on new hardware where the DRM layer is still maturing there might be some glitches to resolve.

Yes, further research does indeed stop me from holding my breath.

I did manage to get Kodi GBM working on one or two Linux distros a few months back and for the most part, Kodi could run rather well overall.

Steps forward in one way or another I guess.

Quote from chewitt

balbes150 is building the image with the Wayland windowing environment, and this restricts you to a single refresh rate because Wayland does not support dynamic refresh rate changes. This is why LE does not use Wayland in official images (only GBM, and Xorg for nVidia). The LE build system supports Wayland because it's used with the Lakka retrogaming fork.

That does explain what is happening then.

Researching this more seems to suggest that right now, manual adjustments using tools such as wlr-randr, which I am not familiar with can sometimes be required.

I dare say that as Wayland development matures, solutions will be created.

I managed to get connection to the repositories. During the initial set-uo, only my local network was auto configured for ethernet.

I had to add the default gateway manually, which opened up access to the internet.

I still can't get past the 30mhz refresh rate but the Orange Pi 5 is not officially supported, so it is entirely reasonable that some functionality might not be there.

The vertical USB 2.0 port is not supported but then it is also problematic on most Linux distros.

Likewise, the USB-C data port is not detected, which is also the case with one or two other distros and full mainline support is, as I believe things, still to come.

Having some fun testing it though and it is worth other Orange Pi 5 users trying it.

Use the LibreELEC-ARMv8.aarch64-13.0-devel-20250607193042-e5590fa-rk3588-roc-pc.img image and change the config file to reflect use of the correct DTB image.

I gave this latest |Wayland version a try on my Orange Pi 5 and it worked.

I ran various tests and although we have software decoding for now, it did a good job where I would expect it to.

Temps seem to be reasonable. I am only using a couple of heat sinks for cooling and the maximum I saw was 61f.

The only oddity I found was that when playing one of my test files, burosch1.mpg, when I tried to back out by pressing the X key during playback, the system crashed but auto recovered within about 30 seconds and booted back to the main menu.

A definite step in the right direction.

Performance was the same as I would expect with a default Kodi install on current Ubuntu or Armbian builds.

Playing around a little more. I noticed that the monitor refresh rate only had one option, 30mhz and I was unable to connect to to either the Kodi or Libreelec repositories to install addons. I just get a timeout error.

But just seeing it booting was rather optimistic.

But the last post in that thread states:

'These are the minimal changes with which KODI launches on rock5b. But there is a bug, a distortion of the image, perhaps it is due to incorrect parameters in the core, HDMI synchronization is disrupted (perhaps the reason is different, this is just my guess).'

So does this not indicate that there are still issues with it creating distortion of the image, requiring a little more work?

Quote from chewitt

Yup! .. but AFAIK the codebase is still lacking HDMI audio and most of the video codecs

See: https://gitlab.collabora.com/hardware-enabl…?ref_type=heads

Thanks for the update and the link, which does indeed show that there is still some way to go for the right elements to be in place.

One stop forward though and with the RK3588 starting to look like another Lemon like the RK3399, any improvements from those outside of the inner Rockchip bubble are going to give some hope to avoid a successive Rockchip failure.

OpenGL ES 3.1 conformance is also another step forward.

With the new release of Linux 6.10 Release, notably the Panthor open-source driver now being an official constituent of the kernel, does this increase the possibility of official LibreELEC support?

Quote from Mister_Sparkle

Hello,

Searched this thread and I did not find specific mention of whether or not this can be used on the Orange Pi 5b? If so, are the steps the exact same as in the original post ?

They would be the same except for the image that you start with, which in your case will be for the 5b model.

The original link will be unavailable but you could use one of the latest builds from https://github.com/armbian/os/releases

You will find that newer releases will be for kernels 5.1 6.1 and 6.8, so begin with the 5.1 and then perhaps see wat happens with the other 2.

Just note that not everything is working in Kodi yet, such as HDR and, if I remember correctly, some 10bit videos.

You may also be interesting in another fork that has been developed where there is great interest in Kodi and things are at a more advanced stage.

Releases · Joshua-Riek/ubuntu-rockchip

Ubuntu 22.04 and 24.04 for Rockchip RK35XX Devices - Joshua-Riek/ubuntu-rockchip

github.com

orange pi 5 plus use kodi ，When playing 4k, the screen goes black, but the sound and subtitles are displayed normally · Issue #815 · Joshua-Riek/ubuntu-rockchip

orange pi 5 plus use kodi ，When playing 4k, the screen goes black, but the sound and subtitles are displayed normally ubuntu24

github.com

Sadly though, right now, because of the failures of both Rockchip and in this case, Orange Pi, all the necessary things to make Kodi fully functional on the RK3588 seem a fair way away and it, IMO, could be 3 years from release that things come together because of the great independent devs and communities.

Quote from chewitt

https://gitlab.collabora.com/hardware-enabl…nline-status.md

AFAIK the HDMI code has either been submitted or is close to being submitted, and panthor GPU support is now merged, but hardware video decode codecs are still missing. It'll be usable at 1080p with software decoding. I'm not sure about 4K media.

At this point someone who cares about RK3588 support should probably submit changes to create an LE13 image. I think we'd have no problem with including backports and patches that are iterating on mailing lists, but we wouldn't accept drivers from the vendor codebase uless backed with a commitment from a "known name" developer planning to rework them in the mid-term.

Thanks for the clarification.

There is one person working on Linux that does seem to show an interest in Kodi, who may perhaps be interested but whether they would be considered a known name I can't know.

But I will make them aware of this thread such that they can make a decision as to whether they wish to approach your team.

With new kernel 6.1 (and even 6.8) development picking up stream as well as many patches and fixes also seemingly being pushed upstream, I was wondering what the general current progress was in respect of the RK3588/s SOC in general.

Just trying to get a baseline, with no unrealistic or unreasonable expectations.