Woa, that’s the same SoC, yeah! I was aware of the Sony Open Devices initiative (and useful docs), in fact. One of the most interesting thing for vendors to achieve kernels closest to mainline is the following:
Every new Android release comes with added requirements and continued development that essentially restarts the entire process. This process of re-implementing features and bug fixes to be able to upgrade devices is costly and does not scale, which makes it difficult to provide upgrades to older devices.
(Emphasis by me)
What’s even more, this upstream pushing clearly reflects the objectives of the Open Source movement started with Linux (among others) of universal collaboration that has being obscured by the vast amount of uncommon Linux devices (Android) launched in recent years (and which has generated a lot of dangerous non up-to-date devices with big security flaws).
Yep! There’s a tendency of forking off a longterm kernel release because they get the most important upstream fixes backported without meddling with internal APIs. Makes it easier to copy-paste non-upstream drivers in. I presume at the time of developing the Snapdragon 835, the latest longterm kernel was 4.4 first released January 2016. In December 2016, the 4.9 kernel was the next one to be labelled longterm. Both have been updated just last week with various fixes (whereas the 3.4 kernel shipped for Fairphone OS first released 20th of May 2012 hasn’t seen a new official release in 9 months now - just non-upstream backports that Google/Qualcomm cluncked on top with their monthly security updates).
You legend! That’s an excellent starting point there. When I get back I’ll turn the opening post into a wiki post (if I can). Can I ask you to share what you have (a github repo with fleshed out DTB, links to how you got the UART working, that sort of stuff)?
I don’t think we would ever use a mainline kernel for running Android just because of the incompatibilities and performance improvements made by Qualcomm.
But for other projects such as postmarketOS a mainline kernel would be great.
And no, I’m not working on it currently because apparently there will be some changes to how eg USB and display gets handled on mainline and without these changes, stuff won’t really work great.
No, it isn’t a technical requirement but one set by Google and is probably just enforced by the Google CTS. (but yes they “require” a new kernel version for Oreo)
Let me correct, 3.4.0 alone does not work with Oreo but 3.4 with backported patches works fine on several devices already. (eg “ambient capabilities” is needed with Oreo and other patches probably too)
But isn’t this the device tree only? An upstream kernel alone still couldn’t address all of the Fairphone’s hardware as it still contains parts which work with closed source/out-of-tree drivers only, am I right?
And I’ve put build instructions on a repo on GitHub linked in the top post. Also if anyone could update that post (eg section “challenges left include” as it’s outdated a bit. Maybe also mention that some stuff is in torvalds’ repo already ).
What are the advantages of having this upstream apart from the obvious one that no longer the FP2 specific code has to be backported? Did I understand correct that this means Oreo may officially run on the FP2?
Probably not. I alone will probably never get all hardware components of the FP2 working nicely and even if, getting Android to (smoothly) run on it is another challenge afaik.
Not related to oreo. Oreo can be done with older kernels. I have not started oreo work as N is still not working properly and no other lineage device anyway has oreo nightly builds.
Google “requires” a 3.18 or 4.4+ kernel for Oreo depending on the device for Google Certification so that’s what I guess is meant with “officially”.
But yes, technically Oreo doesn’t need a new kernel version (except a buttload of backports)
