What is the deal with RockPI4 linux kernel versions?

#1

Can someone please explain a bit more what the deal is with upgrading Debian (or if necessary Armbian) Linux from the 4.4 kernel provided by Radxa to a newer version ?

I have been reading through some threads, but i am still completely confused as to whether or why upgrading to a newer kernel would be different from e.g.: debian on x.86

-> What is my easiest option to get a running debian (or if need be armbian) on a rockpi4 ? I have the radxa provided 4.4 kernel debian running fine on my rockpi4, but i think i have one kernel issue, and i would like to check if it still exists in latest debian kernel (5.3 or so ?).

-> Are there simply no newer kernels on the repositories ? And the repositories are hosted by radxa, and radxa does not care (has time/money) to compile newer kernels ?

-> Why do there need to be rockpi4 specific kernels anyhow, why can there be no more “generic” kernel to avoid having to compile for each different model ? There is enough memory these days to carry boodcode for many many SOCs, right ?

-> where are instructions how i could compile / upgrade myself on debian, and why would that fail more likely than on x86 ?

Thanks so much.

1 Like
#2

You can get an image from Armbian that uses 5.3 or 5.4.

Radxa only maintains images with the vendor kernel they got with the SoC which is rotten, old, and unnecessary, as the RK3399 has near full support in mainline. Just switch to Armbian, and if you need to self-compile a kernel, general instructions related to Debian kernels should apply.

#3

Very short: because x86 world is world of standards, exists “since ever” while ARM is a world of diversity.

Generic (Debian) kernels on ARM cares for basic/generic needs, Armbian - with the same philosophy -cares for that and more - on supported hardware is up to “far far better”. Armbian kernel has overall better support - more enabled or added drivers - than from x86 Debian Buster on my XPS notebook.

Armbian has special hw dependent tools (armbian-config which raspbian-config can’t even compare to), tested experiences and have deep know-how. Armbian is deeply attached to the kernel, maintain many out of the tree kernel patches, while generic distros such as Debian/Arch/Ubuntu/* relies on mainline.

Try some random ARM board with generic Debian and you will be happy if it shows signs of life. Then grab Armbian for supported hardware and you can use it straight away. And rely that it will run your applications for years.

BTW. Modern kernels (5.4.y at this point) always lacks certain functions which exists in development / BSP kernels, where hardware support was initially build on (4.4.y for this board).

2 Likes
#4

Two months ago I spent a week researching on if there is a time to come up with a generic ARM64 kernel that would cover all boards. Actually two kernels. One build for ARM64 and the other for ARM32 / armhf.

Debian and many others provides such kernel. Yes, it is possible. But … its a huge compromise. You have to kill so many functions at this point that its not worth - how to explain users: “we will have only one kernel, but you with this and that board will not have HDMI, nor audio, nor this and that”. This means generic kernel - which already doesn’t have many special functions - must have them even less just because it has to be one.

My estimation is that we need at least 6 (probably 12) months to adjust, drop or RFC the remaining code, which can’t live together at this point,

3 Likes
#5

The mainline kernel we evaluated is not matured enough for massive production yet. If you have doubts, you can check the arm based chrome OS devices. The kernel is maintained by google but most of the devices are still running the old kernel. That’s why google pay collabera to work on the mainline multimedia driver of rockchip platform(rk3399).

On the radxa side, we will work with some open source companies to get the mainline full functional on the ROCK Pi 4. It’s the faster than ourselves to submit patches.

1 Like
#6

Thanks, jack,
What is my best choice right now to check out a newer linux kernel than 4.4 to see if my driver problem is fixed there ? There are some suggestions that i may not fully understand for armbian kernel ?

#7

Armbian is your best option. By far.

#8

Which part you don’t understands?

Armbian is a community project which downloads freely available mainline (or BSP) kernel code, adds value in adjustments, driver porting, debugging, improvements, testings and release that for free for further - that you don’t need to suffer. That code eventually comes to Debian kernel. Sometimes it takes weeks, sometimes years. Folks around the project donates thousands of engineering hours, currently valued around 1.5 mio EUR / year to improve support only for a selection of ARM based boards. Some of hardware sellers & makers supports this initiative, some don’t …

Basically we cover (or assists) in hardware people - chip/board designer (terrible) work.

1 Like
#9

Thanks for the explanation, igorp

I guess purely on a practical level of selecting the right OS for myself, i do not understand how armbian version numbers relate to debian version numbers.

On a more general lack of understanding, how does the whole upstreaming process work, lets say in the triangle of radxa, armbian and debian. If i understood Jack from radxa correctly, they seem to have not done upstreaming (yet), but wanted to work with an open source company to do it in the future, so that one would hopefully be able to run any future debian on rockpis. I can see how armbian is an enhanced downstream system from debian (not distro but build system it seems), but whats the upstreaming policy of armbian ? If radxa for example said “here is some money to the armbian team, please upstream the rockpi changes” ? Or would armbian also attempt to do this even in the absence of explicit sponsoring, etc. pp.

As i said: clueless but curious :wink:

1 Like
#10

It’s a Debian derived distro with a powerful build system (Debian doesn’t have anything like that). What Debian is? Its a compilation of (mainly) community maintained GPL software segments released as Linux/Unix OS under GPL licence. From here you have Ubuntu, Mint, … and lots of smaller ones which are (mainly) remixing those packages, have some specialities or changing logo/wallpaper/appearance without adding value. Kernel - in most cases - comes from one source and bugs are somehow up-streamed. As is.

We are little outside this parameter. Not because we want, but because other ideas are not suitable to cover (Debian like) Linux on single board computers. We maintain our kernels (more of them, compiled for arm/arm64 only) and our package base is different but versions are attached to certain Debian or Ubuntu builds to maintain software compatibility. This means a complex suite, which was designed only for Debian 9 (and doesn’t work anywhere else) works on equivalent Armbian build.

Upstream policy of Armbian?

The same as with Debian and the licence you have: as is.

Armbian is our upstream. The exact same way Debian’s upstream is Debian, Ubuntu’s upstream is Ubuntu, Radxa people only fix their kernel. If you like, you can upstream this opensource work. Why would this be Armbian, Radxa, Debian’s (who exactly from Debian?) or my personal responsibility to care about? Anyone can. You can. You can also hire someone to do that … it only needs time and know-how. Which is expensive and its not so simple to find such people. Not even you have a bag of money. Why Google doesn’t or can’t cover that?

If radxa for example said “here is some money to the armbian team, please upstream the rockpi changes” ? Or would armbian also attempt to do this even in the absence of explicit sponsoring, etc. pp.

Armbian is a non-profit community project. I know its a bit hard to understand. We invest into open source software with or without them. We accept donations which can help on costs - but we have our own businesses and jobs behind. Most of people do this for fun.

They can support us, hire people who do this for money or do nothing more than they already do - high end Linux support can be extremely expensive … while most of people will anyway not notice or need the difference.

#11

Thanks, igorp

Well i guess both Radxa and Armbian do benefit a lot from debian. There would be no linux OS option available on Radxa products without debian and there would be no armbian without debian, right ? If i understand this correctly, then what is the fair way to recouperate ?

I do not know the answer for armbian because one can argue that it helps debian to disseminateto more ‘IOT’ devices by its existance alone, but of course if armbian creates anything that would also be of value in other open source distributions like ubuntu, then it would be nice if that work product was not stuck in armbian but would proliferate through the open source community via debian. Of course one can argue that whoever has the most to gain should be the one doing the upstreaming of that work.

For radxa, the benefits of contributing their work (drivers/patches for their boards) back into debian seems quite obvious given how it helps radxa to save work on continuing to build special images and potentially duplicate work. And by putting them into debian they will also get them into ubuntu and armbian i guess.

#12

Some, but also could be none? And or vice versa. Since anyone can use freely available user space and since kernel - the important and the most expensive part - has very little to do with Debian. Virtually nothing. Debian is a compilation of 3rd party utilities maintained by the community. The exact same way as Armbian is maintained. You can also incorporate our work further and nobody will care about. That’s the point.

It is possible that you are not understanding what I am trying to explain to you.

Corporate Linux distributions repacks and are mainly focused to make money out of and services with help of free software. They work for their interest first, then perhaps for their users - if they pay - and then for some common interests.

Armbian is specialised distribution for single board computers where R&D and support costs is paid from our own pockets. OS scripting was taken from Debian and Ubuntu (which is only slightly repacked Debian in its core) … it can also be Arch, Alpine, Mint, Gentoo or whatever mix of utils you want it to be. That scripting is the cheap component. Any kid can do that.

Don’t tell contributors and makers to contribute more or do the way you want. Contribute. Make it right.

1 Like
#13

Thing is - as far as i understood, it’s not just
“Hey, i have code, upstream it”
It’s more like
“I have code, that i do maintain and which will not disturb other code, that’s code is base, which can be used by many (i.e. rk3399 device tree). Upstream it”
That’s main problem why there is no universal uboot for all boards, yet. Too much difference between them, too much “workarounds”, which may cause conflicts between each one.
So upstreaming to Debian…is a bit hard (in terms of work and time) thing to do i believe.

Also, the main thing is that Radxa is already using rockchip’s base, which already have so many workarounds with close-source solutions (i.e. mali libraries) that it’s literally just not cost time and work to upstream it

#14

Thanks, Dante4.

I was actually not considering pre-linux-kernel code, so in the absence of me having a clue about that code, i will happily trust what you say. There is also this concept of overlays which seems to affect the linux kernel with platform code, but i was hoping that whatever API that has in the linux kernel would then be platform code independent.

Is there any place that documents this whole overlay/u-boot concept ? I could not even find a single documents both the ‘fts’ and ‘devicetreedir’ options in extlinux.conf (which as i hope is the latest stage of u-boot ?

I could also not figure out if its possible to select a different set of overlays for different kernels.

#15

@raidboy iwas advised to read this, wheni first asked what DeviceTree is

1 Like
#16

Thanks, that a very good explanation of the device tree concept.
Any pointer to documentation for the first stage bootstrap, e.g.: what is the Rock PI first looking for on the uSD ?

#17

You can check here:

http://opensource.rock-chips.com/wiki_Boot_option

1 Like