Patches 67-69 were obtained from the armbian community, other patches were created and tested by myself （Modified based on the mainline 5.10 kernel patches）.
dmesg.zip (16.9 KB)
The radxa bsp kernel patches : from 5.10.67 to 5.10.123
1 Like
Welcome to make a PR back.
are the latest rockchip patches also included ?
raxda is built from june
khadas is from july
the friendlyarm is from may if not mistaken
from where they add their own patches , nice that friendly arm says 110 but it has a lot of rockchip patches missing
i mean like this
The only device running with this kernel has HDMI output but is meant to be used headless (3 NIC routerboard R5S) as such I would believe they’re not in a hurry to pull those more recent commits over from Rockchip. At least somebody over there took the efforts to bring 5.10.66 to 5.10.110 (‘FriendlyWRT’ for R5S shipped with this version from the beginning).
Really nice to see each and every RK35xx board vendor re-inventing the wheel 
The code I cloned is based on https://github.com/radxa/kernel/tree/stable-5.10-rock5, which is no big problem for my rock5b, almost all the functions that will be used are ok. Then, I’m not satisfied that the kernel version is only 5.10.66, so the latest goal is to catch up with the progress of the mainline kernel 5.10 (currently 5.10.143).
For each incremental patch, I will try my best to deal with the .rej file, and if it is really impossible to fix, I will give up temporarily, fortunately so far the rate of abandonment is quite low.
Just to be clear: this is not 5.10.66 LTS from kernel.org but some forward ported 2.6 kernel, details here.
As such even the 5.10.66 string is pure cosmetics since to really ensure that RK’s 5.10 BSP kernel is identical with 5.10 LTS someone would’ve to rebase the Rockchip code on top of a clean 5.10.66 LTS. If this didn’t happen nobody knows how far away this RK 5.10 is from 5.10 LTS.
Does that mean going from 5.10.69 to 5.10.123 some of the LTS backports to 5.10 do not apply cleanly and you skipped them?
Yes, there are indeed a small number of patches that cannot be applied. As far as I can observe, the bsp kernel is based on the 5.10 of the android version, and there are some differences from the 5.10 of the LTS. As much as possible, at least 90% of the patches can be applied smoothly. I don’t know what you’re saying about the forward porting of the 2.6 kernel, at least what I’ve observed: this is indeed the 5.10 kernel.
Taking patch 5.10.66-67 as an example, only the following six failed:
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored – saving rejects to file drivers/gpu/drm/drm_dp_mst_topology.c.rej
patching file drivers/media/i2c/imx258.c
Hunk #1 FAILED at 22.
Hunk #2 FAILED at 46.
2 out of 2 hunks FAILED – saving rejects to file drivers/media/i2c/imx258.c.rej
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored – saving rejects to file drivers/scsi/ufs/ufshcd.c.rej
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored – saving rejects to file drivers/usb/gadget/composite.c.rej
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored – saving rejects to file kernel/dma/debug.c.rej
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
5 out of 5 hunks ignored – saving rejects to file sound/soc/rockchip/rockchip_i2s.c.rej
66-67.zip (4.2 KB)
Other versions of the patch are basically similar, some .rej files can be successfully applied with simple modifications, others cannot (abandoned)
That’s not at all what I observed. It was forked at 2.6.32 and then new stable versions were merged in and conflicts resolved by hand. Many many many bugs were not properly fixed, and the difference between this kernel and a real 5.10.66 is larger than between 5.10 and 5.10.66. When I first tried to forward-port this kernel to more recent 5.10, I got many conflicts in important bug fixes that couldn’t be resolved because other prior important fixes had simply been dropped as the result of attempts to resolve merge conflicts in the past.
I’m not judging the people who did that, I know for having been in that positoin that it’s extremely difficult to deal with conflicts in the kernel. But it’s also criminal to maintain a fork for that long a time with only merges, because merges hide mistakes forever by claiming that the entirety of the merged kernel is present there while it’s not, it’s only the result of a manual merge that’s in. BSP kernels ought to be rebased on new major branches. For sure that’s more work for chip vendors, but their efforts would be lowered if they invested the same time trying to upstream more stuff, and their lack of care has for consequences that the claimed 5.10.66 doesn’t have all the fixes that the real 5.10.66 has. That’s just a random piece of shit that nobody knows what’s inside.
3 Likes
Yes, some can. Others can’t because surrounding context is missing or wrong due to previously skipped patches in their tree. I’ve seen some missing locks and some missing checks compared to a real 5.10.66. And by then it was only 5.10.91 that I tried to merge, there were already 46 conflicts… I ended up with something that obviously didn’t build and preferred not to pursue that effort seeing that I was going to have to endorse all their accumulated bugs along the 87515 commits that went into it since the fork of mainline.
Blue text is an URL:
Willy explained there the problem already months ago and did it just now here again.
It’s a huge bunch of code lines with a 5.10 version string. Just like you were abandoning patch pieces that didn’t fit, RK employees did it before. As such we have to expect tons of important (security) fixes missing. Increasing the version number doesn’t bring this bunch of code lines closer to mainline (5.10 LTS).
1 Like
At first I couldn’t believe they were doing this, but then I looked and … OMG. No way in hell I’m going to touch the BSP kernel after this, so I’ll just wait with my purchase until mainline support catches up to at least server use (power, PCIe, memory, sata, etc.).
It this the same deal in Android world? Does Android (Google) really allow vendors to lie about kernel versions as long as the code appears to work?
1 Like
To be honest it’s not lying, the advertised kernel is part of the history, it’s ignorance. It’s just that it got so many unintentional modifications as the result of merge conflict resolutions that it’s very far from the claimed kernel, and such changes are extremely hard to spot.
The best way to see these changes is by running git diff between the claimed kernel version and the whole kernel, and seeing changes that are clearly not related to the BSP. But many of them are less clear because you have large areas where maybe one line came from the intended BSP changes and the rest is just failure to merge new kernel changes in the vicinity that appear as context changes.
Now depending on what you intend to do with that device it may or may not be a problem for you. For the vast majority of users it will only be a problem when they want to refresh the kernel, but by then (6 months / 1 year), most of the device will be supported in mainline (again, also depending on what you’ll do with it).
1 Like
I get the part that pieces of 5.10 kernel are part of the BSP, but I doubt Google does a git diff and code auditing to make sure for example that bugs with memory subsystem or network subsystem had been applied cleanly (AFAIK the kernel is supplied by SOC vendors on Android, and not independently verified). This is just such an unimaginably big trust hole, I never thought it would be done like this. I am OK with trusting Rockchip or Qualcomm that their drivers are written with reasonable care, but until now I thought the 95% of the Kernel they never touch. Clearly my trust in the whole vendor chain was based on bad information
1 Like
Here as well. I always thought Google would require Android SoC vendors to rebase their proprietary code base on the respective AOSP kernel when wanting to support a new Android release requiring a more recent kernel version.
But obviously that’s no requirement and I highly doubt Rockchip are the only ones forward porting since forever. At least Amlogic and Allwinner seem to do the same…
Much less work on their side. I’m still waiting for a widespread old 0-day that would only affect kernels before the last one merged there, but still leave those vulnerable. Maybe the bad practice will change then when they discover that BSP 5.10.XX is still vulnerable to issues that were fixed in Linux 4.4.