Skip to content
This repository has been archived by the owner. It is now read-only.

"The Mainline Kernel" #91

Closed
ollieparanoid opened this Issue Jun 15, 2017 · 20 comments

Comments

Projects
None yet
8 participants
@ollieparanoid
Copy link
Member

ollieparanoid commented Jun 15, 2017

One of the goals of pmOS is to unify multiple devices in using one and the same kernel binary.
For a few selected devices, this goal is coming unexpectedly close already - in the meaning of: the kernel should boot, and we should get output on the serial interface, allowing further development from there:

We won't be able to use Alpine's linux-vanilla for these devices, because:

  • We really need the latest kernel (as support for these devices is being actively developed on)
  • We will need custom patches, until they are all mainlined
  • We will need different config options for the kernel.

Tasks:

  • Create a linux-postmarketos aport based on linux-vanilla
  • Get it working with qemu (should be the easiest)
  • Get it working with nokia-rx51
  • Get it working with lg-hammerhead
  • Close this ticket and continue documentation in the wiki
@PabloCastellano

This comment has been minimized.

Copy link
Member

PabloCastellano commented Jul 17, 2017

JFTR: Sony seems to be a step forward compared to other manufacturers. They have published information on How to build mainline Linux kernel for Xperia devices and do provide patches upstream.

@craftyguy

This comment has been minimized.

Copy link
Member

craftyguy commented Jul 20, 2017

the "get it working with nokia-rx51" task is done :)

@MartijnBraam

This comment has been minimized.

Copy link
Member

MartijnBraam commented Jul 20, 2017

I've compiled a mainline kernel with all the common smartphones enabled (msm, omap, broadcom, mediatek, alwinner, exynos). Here are the kernel sizes compared:

rx51-only kernel: 3.6 MB
kernel with all common smartphone platforms: 4.3 MB

I've not enabled extra drivers for these platforms, just enabled the platform support itself. Not all extra driver stuff can be build as module so it will be slightly larger than this.

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

ollieparanoid commented Jul 20, 2017

Okay, judging from that and how we must keep an eye on the size (#126), it makes lots of sense to ship one kernel binary per board, as you suggested. (Which does not make them any less mainline).

@z3ntu

This comment has been minimized.

Copy link
Member

z3ntu commented Jul 27, 2017

Question: How would this work with the different dts files? While developing the mainline kernel for the FP2, I always just appended the correct dtb to the zImage so is there a way of really having one for all? Or is the goal just "the same source for all"?

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

ollieparanoid commented Jul 27, 2017

We would have multiple dtb files generated, and put the name of the right dtb in the deviceinfo.
postmarketos-mkinitfs appends the correct one then.
That's how it already works for the N900 and the qemu armhf "device" (look in their source for more information).

@MartijnBraam

This comment has been minimized.

Copy link
Member

MartijnBraam commented Jul 27, 2017

@ollieparanoid in the checkboxes above you've added hammerhead, but the hardware for hammerhead is way less supported in mainline than in the lineage kernel and I can add only one kernel package to the hammerhead device file. how should this be handled? A bunch of other devices are gonna have this problem.

An nice overview is from this post on the maemo forums:
https://talk.maemo.org/showpost.php?p=1527669&postcount=1

stuff like the nexus 5x and 6p are listed as "some mainline support" but none of them have graphics yet like the hammerhead.

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

ollieparanoid commented Jul 27, 2017

Whoa, awesome list!
I recommend adding support to our linux-postmarketos package for these devices, and sticking to the Android kernel by default until the mainline kernel is somewhat usable (screen with touch and usb networking are the very basics if you ask me). Then switching to the mainline kernel, but with the option to additionally install the Android kernel. When mainline has all features implemented, we'd move the Android kernel package to unmaintained.

All commands working on the kernel/initramfs have a --flavor command already, which can be used to choose a kernel.

So if you had the hammerhead, and wanted to run it with mainline, you would do: pmbootstrap install --add linux-postmarketos, then pmbootstrap flasher boot --flavor postmarketos.

@craftyguy

This comment has been minimized.

Copy link
Member

craftyguy commented Jul 29, 2017

Should the tasks list be expanded to include new 'official' devices?

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

ollieparanoid commented Jul 29, 2017

I recommend that we close this issue after we added support for hammerhead in the mainline kernel (keeping the mainline kernel optional for hammerhead as written above, because the screen does not work yet). Because when we fill this issue up with mainlining every device (especially the ones where we need to start from scratch), it will get messy.

We could put the mainlining progress of each device in the device's wiki page, and once a specific issue comes up, that someone is actually working on, we could make an issue for that.

Additionally, we could have an "easy to mainline" wiki article (probably that's not the best name), with the list from the initial post combined with information from that maemo thread and what else we can find.

What would you think about that?

And not directly answering your question, but related to this issue: What I really would like to have is a "mainlining guide" in the wiki, which describes the steps necessary to get the mainline booting on the device (port the dtb file over, if there is one, or write it from scratch by looking at the Android kernel source? How does that work?), no matter how much of a rough draft it would be - we could flesh it out when we're actually doing it. At some point it should be possible to have a relatively straight forward guide (assuming we can put up all the work to really mainline a few devices). Dear reader, if you know anything about that topic, please start such a wiki page :) (Also if we would see, that there are repetitive tasks involved, we could write some tooling to assist the mainlining.)

@craftyguy

This comment has been minimized.

Copy link
Member

craftyguy commented Jul 29, 2017

@ollieparanoid yea that makes sense

@MartijnBraam

This comment has been minimized.

Copy link
Member

MartijnBraam commented Jul 29, 2017

I've written a quick wiki page about the mainline stuff we have in the master branch currently:
https://github.com/postmarketOS/pmbootstrap/wiki/The-mainline-kernel

@z3ntu

This comment has been minimized.

Copy link
Member

z3ntu commented Jul 30, 2017

@ollieparanoid It's pretty easy getting mainline = serial output of the boot process plus shell in the initrd. The really complicated part is getting different components of the device to work. A major issue I have currently is that I don't know how I can find out what of the different attributes for the Qualcomm regulators are needed or not. For other parts I was very lucky that some msm8974 devices already have kinda good mainline support (like hammerhead or honami) so I could copy/follow these devices. So yes, it would be great to have a reference for at least Qualcomm devices to kind of know what you are doing.
Also, for the panel driver, there's a guide: https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting
And my Linux tree with very limited FP2 support: https://github.com/z3ntu/linux/commits/FP2-cleaner-3

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

ollieparanoid commented Jul 30, 2017

Outstanding, @MartijnBraam! I have expanded the wiki page a bit and added the DSI panel driver link from @z3ntu. Good to hear, that we have another dev with kernel development knowledge around (most of us do not have that skill yet, including myself).

@MartijnBraam

This comment has been minimized.

Copy link
Member

MartijnBraam commented Aug 18, 2017

I found a flaw in your plan to use --flavor to switch kernels, For the hammerhead the deviceinfo is different because I need to specify the dtb and modules from the kernel which is different between mainline and the lineage kernel. I've just patched the device package in the feature/linux-postmarketos-hammerhead branch.

I also don't see a better way to handle kernel flavors that have this much differences but maybe any of you do?

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

ollieparanoid commented Aug 19, 2017

Idea: Let's ignore dtb and modules if none exist for the current kernel (so only if there are 0 dtb files and 0 modules). Would that work?

@montvid

This comment has been minimized.

Copy link
Contributor

montvid commented Sep 10, 2017

I can test a mainline kernel on Nexus 7 2013 if someone gives me the binaries. I am trying to build the linaro build now.

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

ollieparanoid commented Sep 11, 2017

@montvid, the nexus 7 2013 will very likely not work out of the box and no one has customized our linux-postmarketos package for it yet. However, I invite you to familiarize yourself with pmbootstrap and try it out for yourself. So if you have some time and want to learn something new: Start with the porting guide and a known working Android kernel first, then do the mainline kernel as second step. If you have further questions, please ask in the chat or open a new issue here (this issue is more about how we package one mainline kernel, not so much about specific devices). Thanks for your interest in postmarketOS!

@zhuowei

This comment has been minimized.

Copy link
Collaborator

zhuowei commented Sep 23, 2017

I tested the mainline kernel support for the Nexus 6P: I was able to build a kernel that boots, but it crashes somewhere when initializing drivers, and I couldn't get a crash log since I don't have a serial adapter. There's a presentation by Jeremy McNicoll about the Nexus 6P upstreaming effort at https://events.linuxfoundation.org/sites/events/files/slides/JRM_NEXUS_ELC_2017.pdf which says that the 6P should be able to boot to a serial terminal, so not sure what I'm doing wrong. I'll update the Nexus 6P wiki page with more information later.

@bhush9

This comment has been minimized.

Copy link
Collaborator

bhush9 commented May 13, 2018

Can we close this now? ;)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.