Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Unified linux-postmarketos kernel for qemu and n900 #228
The creates the
I've put the generated dtbs in
I am glad, that you are working on this!
However, I think we need to discuss the handling of the board architectures a bit more. The two of us agreed on having multiple builds for different boards is a good idea (dear reader, if you think otherwise, please let us know).
So with the current PR you're just ignoring all other boards, but that won't scale. I have two approaches in mind:
Another idea I have is writing some Python code, so we can have
So my proposal would be 2. + aportgen, what do you think, everyone?
My current plan was ignoring the size of the kernel until it becomes a real problem since not a lot of devices have mainline kernel support yet. The devices that have very tiny boot partitions aren't devices that have mainline support at all. Splitting this up in seperate packages for different board architectures is relatively easy (just duplicating the package and changing the config) or can be done with the subpackage support in alpine.
I'm currently modifying the APKBUILD to be closer to the linux-vanilla one again since we have module loading working for this so it also generates a linux-postmarketos-dev package.
Enableing more architectures in the kernel doesn't seem to increase the build time a lot, it just makes the resulting kernel image bigger.
referenced this pull request
Jul 23, 2017
We could do one of the following:
I think the second solution is more elegant, what do you think?
I think it's better to use
For devices with dtb:
and for devices without dtb (I don't think any mainline devices would boot without dtb) you just don't have the -dtb file.
The non-mainline devices currently don't have the deviceinfo_dtb set and write the image+dtb to the plain vmlinuz-flavor file so they keep working without a change.
I'm hitting an issue now with mkinitfs. It's called twice directly in succession with different parameters.
This kernel seems to work way better on the n900 than the one currently in the master branch (because the display boot bug is dependend on some race condition and this magically makes it work better)
The x86 qemu build can't run yet because of #260 and the qemu armfh build doesn't have input working but still boots fine.
@ollieparanoid how about merging the progress so far to improve the development for the n900 (and let more people mess with qemu)
Sorry, that it too me so long to answer. I'll be happy to merge this after the typo has been corrected.