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.
The radxa bsp kernel patches : from 5.10.67 to 5.10.123
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.
Probably it would be nice to have a list for what patches as been dropped. We cannot know what Rockchip did but at least our self-made patches could have some record like this?
You could have known if they rebased. Since they merged, all the patches are there, it’s just that conflicts were not correctly resolved and cannot be spotted anymore once the commit is created, by definition. That’s why we’re saying that what they’ve done is a terrible unauditable and unfixable mess.
1 Like
Isn’t 5.10 is a bit too old now?
If you are talking about the upstream 5.10, then it’s an LTS kernel with enough vendor interest and has extended support till Dec, 2026. It is “old” because it is initially released about 2 years ago, but it is still receiving updates.
But the thing is that we are using a vendor kernel AND a lot of patches getting dropped to make vendor(rockchip)'s downstream patch work, and we will not receive updates as soon as a new upstream 5.10.x is released, and this would be the real problem to make our kernel “old”.
Now even Radxa uses the 5.10.110 branch (merged in some Google kernel stuff) FriendlyELEC ships with since months…
Do you mind explaining what this means in terms of diverging from mainline as discussed above?
I think willy explained the situation very well, or could you ask more specifically what you want to know?
I can not say anything about the Radxa Kernel yet but I may help to understand what is inside the
Rockchip Kernel (develop-5.10 which is current at 5.10.110).
The 5.10 branch started here (in March 2021):
They did a full reset of all files within one commit. At this point it was a clean Android 5.10.19 (clean files not clean history), only extra files/folders that are not part of mainline or android kernel (like thirdparty GPU and WiFi drivers) stayed in the tree.
From March 2021 to September 2022 they commited 5568 own patches and about 150 other patches which are not just to add the old stuff they also removed obsolete parts (like old wifi/gpu drivers), bug fixing and adding support for new SoCs etc.
If you want to do a closer look at this you can replay the patchset on a clean Andoid Kernel by using this:
https://seafile.servator.de/sbc/odroid/build/patches-rk-develop-5.10-20220930-2.0.zip
The README.txt describes how do do this.
The result will be equal to rockchip-linux branch develop-5.10 without the huge history.
PS: This is more for research not to start a kernel based on the full patchset.
2 Likes
The radxa kernel is based on rockchip develop-5.10, the difference is shown in the following archives.
stable-5.10-rock5:
109 extra patches/commits (94 radxa, 6 rockchip, 9 others)
https://seafile.servator.de/sbc/radxa/build/patches-radxa-5.10-20221101-1.0.zip
linux-5.10-gen-rkr3.4:
278 extra patches/commits (140 radxa, 121 rockchip, 17 others)
https://seafile.servator.de/sbc/radxa/build/patches-radxa-5.10-20230209-1.0.zip
4 Likes