Nothing about RK 3566

deleonkikko · May 7, 2024 at 10:09 PM

Code

Waiting for the final version of Libreelec 12 (Omega) for the new Orange pi 3B and finally the board is still in the box...

Unfortunately I am not a programmer nor do I have the knowledge to do so, but I thought someone would make an image for the RK 3566.

It's a shame. It is assumed that when a higher version comes out, it should support new boards, but in the end it is a version for the same thing that we already have.

The same case is with the Rock pi 4C+, which was waiting for the latest version in the hope that there would be Libreelec for this board as well.

From here I volunteer to try things if someone makes an image for these two plates because I don't know how this works. I don't know if you buy the plates or the manufacturers give them to you.

I hope that soon we will all be able to enjoy the new versions of Libreelec on newer boards.

In the end, with new versions that include improvements, old boards will surely not work because they are obsolete.

Thanks to the team for all the work they do and hopefully soon we will have images for the new and more powerful boards that are released daily.

Good night

Display More

Code

frakkin64 · May 7, 2024 at 11:48 PM

LE is just a Kodi-focused Linux distribution. It seems quite apparent to me that what drives new LE versions is Kodi new versions (not board support, not to say it doesn't happen but the major version cycle is tied to Kodi's).

I think your expectations are misdirected, you should talk to Orange Pi about why they don't get their board supported by Mesa, Linux, and other projects that get rolled into LE as a distribution. Best way to deal with it is just don't buy these boards that don't make the effort. Raspberry Pi 5 has support because Raspberry Pi paid Mesa, Linux, and other developers to write the software and push it to those same projects.

**chewitt** · May 8, 2024 at 4:49 AM

Raspberry Pi did not pay mesa; they paid a well-known and respected developer shop with tons of mesa experience. Work on the mesa changes needed for RPi5 was done 6-9 months ahead of product launch so that on announcement day (one month before public availability) a refined pull-request could be submitted to add mesa support. Similar things were done with essential Linux kernel and DRM (VPU driver) changes too, and their own firmware blobs were in a "final" and well tested state. The result was: on public availability date -90 it was possible to create a shipping/releasable product on an RPi5 board. Some of the LE staff had alpha boards earlier; but things were already at a point of maturity where creating an initial RPi5 image took me 58 mins from unpacking the board sample to booting a daily-usable LE image on it; and that includes 30 mins image compile time. I'm lucky to have a fast box for compiling on, but that speed and simplicity was really about RPi5 being derivative from RPi4, and RPi devs having all software in a usable state. Raspberry Pi understand that average hardware with amazing software support trumps amazing hardware with average software support.

Rockchip and most other SoC vendors simply don't understand that software-focus, it's not in their hardware-oriented corporate DNA. They still ship average/poor "Hey Mom, it booted!" quality Board Support Package (BSP) kernels with their new products. In the case of RK3588 it was also missing major subsystems like HDMI. The Engineering saying "You can have it fast or cheap, choose which one" applies; and Rockchip and other vendors consistently pick "cheap" and rely on "the community" to rework their BSP code and write missing drivers from scrtatch, then send it upstream to the kernel. They do have staff assisting kernel development, but the lions-share of the upstreaming effort is done by hobbyist developers in their spare time, or professional Linux development shops working pro-bono because they hope to gain in the long-term from acquiring expertise and reputation, and becoming the go-to destination for funded commercial projects. Those folks are amazing, but they understandably prioritise pro-bono work below anything chargeable, so the process still runs slow.

RK3588 shipped two-years ago this week. It is still 6-9 months away from a viable LE image with hardware decoding; although we will probably add support for boards in a "software decode only" state earlier. The same is probably true of RK3568 which does have easier decoder needs.

balbes150 has some LE images for RK3568 available. I can't speak for how things run; there's a language barrier and Oleg hides sources on bitbucket behind a terrible GUI and obscures development with "one month of changes grouped in a single commit" which complicates change tracking to the point where nobody can be bothered to make the effort.

There is also https://github.com/LibreELEC/Libr…ment-2097736658 which shows promise; though it sounds like codecs are still incomplete or missing if things are limited to 1080p (sounds like software decode or legacy VOP use).

**ilmich** · May 8, 2024 at 11:27 AM

deleonkikko Regarding the Rock pi 4C+ I saw that the device trees in u-boot and mainline kernel are present. So a porting attempt is possible. Unfortunately, I don't have that board so if you can help me with tests I can propose it as a new device (to be included in libreelec 13, to check if it can also be added later in libreelec 12)

deleonkikko · May 8, 2024 at 4:28 PM

Before continuing with the topic, I want to say that this is not a complaint or a bad criticism of your work. Not at all. I love the work they do to make us all happy. But I thought it was easier to develop for new boards than to adapt to boards that have been on the market for a while. I am willing to collaborate as a tester as I have both boards. so I am available to anyone who needs me

frakkin64 · May 8, 2024 at 9:43 PM

Quote from chewitt

Raspberry Pi did not pay mesa; they paid a well-known and respected developer shop with tons of mesa experience.

Yeah that's what the context of "Mesa developers" meant as in someone with Mesa development experience, not specifically the project.

The problem is consumers seem to either be chasing the cheapest SBC/TV box or the most powerful SBC, and then the complaints start rolling in on every Linux distro about support. I played around enough boards, and pretty much the realization is it's either a Raspbery Pi or a N100 mini PC at this point. Everything else is just too much of a time sink, and giving them any money just continues to encourage this behavior.

**chewitt** · May 9, 2024 at 6:25 AM

Quote from deleonkikko

I am willing to collaborate as a tester as I have both boards. so I am available to anyone who needs me

The world is full of willing testers and devoid of people with the time and/or skills to write complex kernel drivers pro-bono.

buzzmarshall · May 9, 2024 at 6:00 PM

Ive been doing this since before sites like this even existed as i was one of the original hackers to put linux on the original so-called android boxes and everything Chewitt says hits the nail right on the head. Even after all these years this part of the equation has not changed as the factories pump out crap without much concern for software as they pay for basic canned versions of Android to make their hardware work and then leave the product to move on something newer that's easy to sell with inflated talked about what the new hardware can in theory run. Anyone that has been at this for awhile quickly learn that specs in theory and whats really available are very seldom the same in practice...

!st it was the Android box market, now its the Small Embedded board market but the tactics are the same. People should just listen to others like Chewitt here and pay attention to what they have working and purchase based on that and NOT some BS dealer trying to sell their crap based on new device specs.

just my 2 cents as i long retired and moved to other things to play with.

On another note... couple of years ago i bought a HK1 Rbox R2 which is a RK 3366 device and tho sticking linux on it is not all that hard its still the same old story with the gpu issues and hardware decoding even when doing all my own developing and for a hobby its just easier to go buy something that you know is better suited and further down the development chain that others on sites like this use and move on.

The real long and short of all these issues are in the fact the GPU development is a protected environment where IP values are so great that getting any real software/firmware that truly works with the codecs is a game for the rich as no corporate company like ARM is going to stray from its revenue stream is make the info available as a good part of their business model is based in IP and licencing which none of the manufacturers will pay for and in the long run has proven to NOT effect their sales, so they leave to places like this to bail them out with the public and crap they sell them.