Hi, I was pleased that it was quite feasible to upgrade CM3 to almost latest kernel using Radxa bsp tool and the latest target. The compilation involved patching vanilla kernel which is perfect.
Please does the same path work for RK3588-based boards too? Will ‘./bsp linux latest’ generate deb suitable for the RK3588? I kind of do not understand how the same kernel package would work on widely different boards if no target board were specified.
The competing RPi5 has patched 6.6 in their kernel repo, but RK3588 is a more advanced technology…
It will still be aligned with the Android LTS I guess.
Has some great Ubuntu images but also does an experimental mainline.
Mainline support is sort of getting to that 80/20 rule where for most its all supported.
Gpu at a guess is still a few releases away
Should be interesting though as according to the above they have code to test…
Currently people are stuck with a headless server but already past the 80/20 ratio of done, but the HDMI & GPU is an issue to many, but looking like ‘Soon’?
The ‘latest’ option of bsp will compile the specified kernel (6.5.5 in that case), I tested that on CM3, but the question is if all patches are there to make some RK3588 board working upon building the image with rbuild.
Thanks a lot. I am looking at options for using the latest kernel which allows using latest upstream patches and creating/submitting to upstream whatever patches necessary to parts like dwc3, f_uac2 etc which will highly likely be necessary for my intended project. All these parts keep receiving a steady flow of critical patches. Running ancient and heavily modified 5.10 is of zero use for this purpose.
But I would assume Radxa cares about upstream and does not want to be stuck with 5.10 android kernel.
Rockchip has a lot of Android aimed Socs so likely they will continue as the BSP Board Support Package follows the Android port to Linux kernel of same version. Likely the next LTS will be avail for the BSP but I am sort of confused at which LTS Android is on and think its still 5.10 based.
6.5.5 is a stable mainline Linux kernel with 6.5.7 of that stable version being the latest, but for Radxa its what they get given than what they wish for as much is Rockchip with the Linux LTS being 6.1.57 and Android lags behind that.
If you want bleeding edge then the above with Joshua Rieks’s Experimental Mainline.
Boris Brezillon: Oct 04, 2023 at 08:26 AM
A second version of the kernel driver has been posted a couple month back and we are about to post a v3. Development branches can be found here and here if you want to play with it.
So you can test the GPU but the HDMI is still WiP but that is between Collabora, Rockchip & Arm.
Presuming Radxa will offer both a Android based LTS BSP and Mainline LTS when given.
Problem with mainstream is that functionalities are developed and ported slowly while HW sales wants that all / most of HW specific features works while this is sadly only possible Android sh* way … Mainline process takes years and from business perspective, to not close down their sales business, its best to wait that end users applies as much pressure to community developers and business subjects to steal or pay for this work as they are tired of their useless BSP kernel.
Mainstream development, support and maintainace is not with particular vendor reach. Mainstream is hard and expensive also because its never ending story, has to be done outside this small egocentric world, and things needs constant maintenance which is nobody willing to admit. And because of constant present piracy. It is very hard for open source developers to get paid for what they do. Some are trying to maximize profits by supporting open source projects that are focused in stealing from developers. There are always people that are willing to play dirty.
To better understand business paths behind attitude towards open source and upstream: even Armbian (or some other group of open source developers) ported most of the functions to mainline for some particular boards on their own and fully on their private expense, because users wanted and asked for, Radxa rather choose to pay(!) pirated TwisterOS project to intensify pressure. Twister is just some small amateur project which did some wallpaper changer application and were driving one of many distros for Rpi, that didn’t do anything valuable. They just did what anyone can do. They downloaded Armbian and start selling it as their own work without any shame and with full Radxa support and even small sponsorship. This is how this “business” works. Sponsoring FOSS pirates is just business optimization. This venture eventually fall apart since it was executed in amateur fashion and because actors soon realized into what they were lured. This attempt failed after couple of months with a big loss for the care you are asking and assuming.
That was several years ago. Today, Radxa is still doing the same, just with different corruption willing partner [1] and not that obvious. Its all about ego and control? They rather put efforts to crush community software and compete against community development efforts instead of helping them helping you.
Armbian (and its forks), community, provides / sponsors ARM single board computers buyers with well maintained and by all means better quality, open, reviewed, mainline based (maintained by more then one person) Debian / Ubuntu images with better framework for past 10 years. Builds are available at once when basic features works. It would be in users interest to contribute to upstream or at least to mid-stream (Armbian). But they don’t accept that.
Business paths are almost never logical, but perhaps this explains some aspects.
I think @balbes-150 Armbian images already have working HDMI, but all this is still not for end users. I do run two Rock5 as a build runner for about a month without any issues. With 5.10.y it was crashing constantly.
Joshua runs this as his private project but shares everything back to Armbian common efforts. He is one of those rare people / projects that doesn’t care just for his / their own benefit.
For that Android kernel is not worth wasting words, but also what will come out here will be heavily modified around probably 6.1.y which is not in best shape in general. Quality of maintaince is questionable from the concept, but I will skip from commenting.
There is not much they can do but to wait and hope. Investing into upstream is not in their business interest and there is a problem that hardware is obsolete before it reaches solid upstream support. Hardware is not hot forever and new variants are constantly coming out …
@RadxaYuntian If patch header is absent, open a ticket and ask politely for patch changing service. Solving this way is not right way. Remember that we have no budget to work with you, so it can take a while. This is the only reason why you have to wait.
We use git am to apply patches which expects well-formatted patches. I’ll create issues when I encounter them again.
@Pavel_Hofmanbsplatest profile is mostly used for internal development instead of a real usable kernel. I use it to check the build infrastructure, while Naoki uses it sometimes to test maillist patches.
You could change fork.conf with following settings to build against trunk:
We have engine to check for defects and reformat patches on the fly.
Perhaps I was not clear enough: please fix this one way or another as it is unacceptable that you are using your header with our work. If you don’t have time to do it right, perhaps just remove patches? This is quick and painless.
Gentlemen, thanks a lot for important info, now I understand the principles behind a bit more.
That Collabora enablement page shows that 6.4-6.6 received lots of RK3588-related patches , I will try the upstream main branch and see how far I can get.
Your problem. We never developed this for you, but for users. Patch is incomplete, but nobody can complain to us because its incomplete. If you don’t have interest to finance this (and everything else) work and to its completion
delete (problematic) patches?
Or open a ticket. I am aware they are not completed, I know what has to be done, but this is just a one problem on the list with 1000+ others and will take years to fix. Which is your fault too. All this time conflict will exists, unless you remove all problematic patches now.
Things are looking very good with the RK3588 as the maninline submissions have come thick and fast for a SoC that was heavily delayed due to fab queues and covid.
@igorp If you stopped spamming support and maintainace sales speak and maybe contributed in any form of reply a simple ‘please donate’ or link would likely suffice.
Thanks for the mainline ubuntu link, I could start with that, even rebuilding kernel may be easier with that. I do not care about GPU performance (for now), only SSH->CLI work anyway.
Thank you for your optimism, your support for the developer and for providing the link to the image. I just looked at it and my first impression was very good. I’ll keep testing but this image is already on top of the list for now of all tested images.
@igorp: Igor, IMO by “contributed” @stuartiannaylor did not mean your contributions to (not only) the armbian project (why would anyone question that?), but posting (contributing) to this thread - that a link to “donate” may do a better job
Taking 1 USD but making 1000 USD of costs is not the best survival strategy for non profit organisations. I wish you all the best by trying to run something similar in a hostile environment as this.
